FTP와 HTTP란 무엇인가요?

범주: 컴퓨터/네트워크>> 인터넷

문제 설명:

FTP 및 HTTP란 무엇입니까

분석:

FTP(파일 전송 프로토콜)는 인터넷 사용자가 파일을 전송(파일 업로드 및 다운로드 포함)하기 위해 개발된 통신 프로토콜입니다. FTP 파일 전송을 구현하기 위해 FTP 프로토콜을 지원하는 소프트웨어입니다. 연결의 양쪽 끝에 설치되어 있어야 합니다. 컴퓨터에 설치된 소프트웨어를 FTP 클라이언트 소프트웨어라고 하며, 서버의 반대쪽에 설치된 소프트웨어를 FTP 서버 소프트웨어라고 합니다.

사용 방법. 터미널 FTP 소프트웨어는 매우 간단합니다. 시작한 후 먼저 원격 호스트와 연결을 설정한 다음 원격 호스트에 전송 명령을 실행해야 합니다. 원격 호스트는 명령을 받은 후 응답하고 현재 사용되는 올바른 명령을 실행합니다. Windows 시스템 FTP 소프트웨어는 CUTEFTP입니다. 즉, 사용자가 특정 호스트에 등록 및 승인되지 않은 경우, 즉 사용자 이름과 비밀번호가 없으면 호스트와의 파일 전송이 불가능합니다. 이를 허용하는 익명 FTP 서버의 경우 사용자는 로그인 시 사용자 이름으로 익명을 사용하고 비밀번호로 이메일 주소를 사용하여 무료 리소스를 얻을 수 있습니다. =========== ===============

WWW의 핵심 - HTTP 프로토콜

우리 모두가 그렇듯이 인터넷의 기본 프로토콜은 현재 널리 사용되는 TCP/IP 프로토콜입니다. FTP와 ArchieGopher는 TCP/IP 프로토콜을 기반으로 하는 응용 프로그램 계층 프로토콜입니다.

주요 프로토콜은 다음과 같습니다. WWW 서버가 사용하는 프로토콜은 하이퍼텍스트 전송인 HTTP 프로토콜입니다. HTTP 프로토콜이 지원하는 서비스는 WWW에만 국한되지 않고 다른 서비스일 수도 있으므로 HTTP 프로토콜을 사용하면 사용자가 다른 프로토콜을 사용하여 액세스할 수 있습니다. FTP, Archie, SMTP, NNTP 등과 같은 통합 인터페이스에서 다양한 서비스를 제공합니다. 또한 HTTP 프로토콜은 이름 서버 및 분산 개체 관리에도 사용할 수 있습니다.

2.1 HTTP 프로토콜 소개.

HTTP는 간단하고 빠른 방법으로 인해 1990년에 제안된 객체 지향 프로토콜입니다. , 지속적으로 개선되고 확장되어 현재 WWW에서는 HTTP/1.0과 HTTP/1.1의 6번째 버전이 사용되고 있으며, HTTP-NG(NextGenerationofHTTP)에 대한 권장 사항이 작성되었습니다. >

HTTP 프로토콜의 주요 기능은 다음과 같이 요약할 수 있습니다.

1. 클라이언트/서버 모드를 지원합니다.

2. 간단하고 빠릅니다. 클라이언트가 서버에 서비스를 요청할 때 요청 방법과 경로만 전송하면 됩니다. 일반적으로 사용되는 요청 방법은 GET, HEAD 및 POST입니다. 각 방법은 클라이언트와 서버 간의 다양한 연결 유형을 지정합니다.

HTTP 프로토콜의 단순성으로 인해 HTTP 서버의 프로그램 크기가 작기 때문에 통신 속도가 매우 빠릅니다.

3. 유연성: HTTP는 모든 유형의 데이터 개체 전송을 허용합니다. 전송되는 유형은 Content-Type으로 표시됩니다.

4. 연결 없음: 연결 없음의 의미는 각 연결이 하나의 요청만 처리하도록 제한하는 것입니다. 서버는 클라이언트의 요청을 처리하고 클라이언트의 응답을 받은 후 연결을 끊습니다. 이 방법을 사용하면 전송 시간이 절약됩니다.

5. 상태 비저장: HTTP 프로토콜은 상태 비저장 프로토콜입니다. Stateless는 프로토콜에 트랜잭션 처리를 위한 메모리 기능이 없음을 의미합니다. 상태가 없다는 것은 후속 처리에 이전 정보가 필요한 경우 다시 전송해야 하므로 연결당 전송되는 데이터 양이 증가할 수 있음을 의미합니다. 반면에 서버는 이전 정보가 필요하지 않을 때 더 빠르게 응답합니다.

2.2 HTTP 프로토콜의 몇 가지 중요한 개념

1. 연결: 서로 통신하는 두 애플리케이션 사이에 설정되는 전송 계층의 실제 순환입니다.

2. 메시지: HTTP 통신의 기본 단위로, 8개의 튜플 구조로 구성된 시퀀스를 포함하며 연결을 통해 전송됩니다.

3. 요청(Request): 클라이언트가 서버에 보내는 요청 정보에는 리소스에 적용된 메소드, 리소스의 식별자, 프로토콜의 버전 번호가 포함됩니다.

4. 응답 ( 응답): HTTP 프로토콜의 버전 번호, 요청 상태(예: "성공" 또는 "찾을 수 없음") 및 문서의 MIME 유형을 포함하여 서버에서 반환된 정보입니다.

5. 리소스: URI로 식별되는 네트워크 데이터 개체 또는 서비스입니다.

6. 엔터티: 요청 또는 응답 메시지에 포함될 수 있는 데이터 자원 또는 서비스 자원의 반영을 특수하게 표현하는 방법입니다. 엔터티에는 엔터티 헤더 정보와 엔터티 자체 콘텐츠가 포함됩니다.

7. 클라이언트: 요청 전송을 목적으로 연결을 설정하는 애플리케이션입니다.

8. 사용자 에이전트(Useragent): 요청 클라이언트를 초기화합니다. 이는 브라우저, 편집기 또는 기타 사용자 도구입니다.

9. 서버(Server): 연결을 받아들이고 요청에 대한 응답으로 정보를 반환하는 애플리케이션입니다.

10. 오리진서버(Originserver) : 주어진 리소스가 상주하거나 생성될 수 있는 서버이다.

11. 프록시: 서버나 클라이언트 역할을 할 수 있는 중간 프로그램으로, 다른 클라이언트에 대한 요청을 설정합니다. 요청은 가능한 번역을 통해 내부적으로 또는 다른 서버를 통해 전달됩니다. 프록시는 요청 메시지를 보내기 전에 요청 메시지를 해석하고 가능하면 다시 작성해야 합니다.

프록시는 방화벽을 통해 클라이언트를 위한 포털 역할을 하는 경우가 많습니다. 또한 사용자 에이전트가 완료하지 못한 프로토콜을 통한 요청을 처리하는 도우미 애플리케이션 역할도 할 수 있습니다.

12. 게이트웨이: 다른 서버를 중개하는 역할을 하는 서버입니다. 프록시와 달리 게이트웨이는 요청된 리소스에 대한 원본 서버인 것처럼 요청을 수락합니다. 요청 클라이언트는 자신이 게이트웨이를 처리하고 있다는 사실을 인식하지 못합니다.

게이트웨이는 방화벽을 통해 서버측 포털 역할을 하는 경우가 많습니다. 게이트웨이는 HTTP가 아닌 시스템에 저장된 리소스에 액세스하기 위한 프로토콜 변환기 역할도 할 수 있습니다.

13. 채널(터널): 두 연결 사이를 중계하는 역할을 하는 중개 프로그램입니다. 일단 활성화되면 채널은 HTTP 요청에 의해 시작될 수 있지만 HTTP 통신에 속하는 것으로 간주되지 않습니다. 릴레이된 연결의 양쪽 끝이 닫히면 채널이 사라집니다. 채널은 포털이 반드시 존재해야 하거나 중개자가 릴레이된 트래픽을 해석할 수 없는 경우에 자주 사용됩니다.

14. 캐시: 응답 정보의 로컬 저장소입니다.

2.3 HTTP 프로토콜의 작동 방식

HTTP 프로토콜은 요청/응답 패러다임을 기반으로 합니다. 클라이언트는 서버와 연결을 설정한 후 서버에 요청을 보냅니다. 요청 형식은 통일된 리소스 식별자, 프로토콜 버전 번호, 요청 수정자를 포함한 MIME 정보, 클라이언트 정보 및 가능한 콘텐츠로 구성됩니다. 요청을 받은 후 서버는 해당 응답 정보를 제공하며, 그 형식은 정보의 프로토콜 버전 번호, 성공 또는 오류 코드, 서버 정보, 엔터티 정보 및 가능한 내용을 포함하는 MIME 정보를 포함하는 상태 줄입니다.

많은 HTTP 통신은 사용자 에이전트에 의해 시작되며 원본 서버의 리소스 요청을 포함합니다. 가장 간단한 경우는 아마도 사용자 에이전트(UA)와 원본 서버(O) 간의 단일 연결을 통해 수행될 것입니다(그림 2-1 참조).

그림 2-1

요청/응답 체인에 하나 이상의 중개자가 나타나면 상황은 더욱 복잡해집니다.

중개자에는 프록시, 게이트웨이, 터널의 세 가지 유형이 있습니다. 프록시는 URI의 절대 형식을 기반으로 요청을 수락하고 메시지의 전부 또는 일부를 다시 작성한 다음 URI 식별자를 사용하여 형식화된 요청을 서버에 보냅니다. 게이트웨이는 다른 서버 위의 계층 역할을 하며 필요한 경우 요청을 기본 서버 프로토콜로 변환할 수 있는 수신 프록시입니다. 채널은 메시지를 변경하지 않는 두 연결 간의 중계 지점 역할을 합니다. 채널은 통신이 중개자(예: 방화벽 등)를 통과해야 하거나 중개자가 메시지 내용을 식별할 수 없는 경우에 자주 사용됩니다. 그림 2-2

위의 그림 2-2에서는 사용자 에이전트(UA)와 원본 서버(O) 사이에 세 개의 중개자(A, B, C)가 있음을 보여줍니다. 전체 체인을 통한 요청 또는 응답 메시지는 4개의 연결 세그먼트를 통과해야 합니다. 일부 HTTP 통신 옵션은 가장 가까운 연결, 채널이 없는 이웃, 체인의 끝 또는 체인을 따른 모든 연결에 적용될 수 있으므로 이러한 구별이 중요합니다. 그림 2-2는 선형이지만 각 참가자는 여러 동시 통신에 참여할 수 있습니다. 예를 들어, B는 A를 통하지 않고 많은 클라이언트로부터 요청을 받거나 C를 통하지 않고 A에게 요청을 보내는 동시에 A의 요청을 처리할 수도 있습니다.

비활성 채널에 대한 집계는 요청 처리를 위해 내부 캐시를 활성화할 수 있습니다. 캐싱의 효과는 체인에 있는 참가자 중 하나가 해당 요청에 대해 캐시된 응답을 가지고 있는 경우 요청/응답 체인이 단축된다는 것입니다. 다음 그림은 결과 체인을 보여줍니다. 조건은 UA 또는 A가 캐시하지 않은 요청에 대해 B가 C를 통해 O로부터 이전 응답의 캐시된 복사본을 가지고 있다는 것입니다.

그림 2-3

인터넷에서 HTTP 통신은 일반적으로 TCP/IP 연결을 통해 발생합니다. 기본 포트는 TCP80이지만 다른 포트도 사용할 수 있습니다. 하지만 이것이 HTTP 프로토콜이 인터넷이나 다른 네트워크의 다른 프로토콜 위에 완성될 수 있다는 의미는 아닙니다. HTTP는 안정적인 전송만을 의미합니다.

위의 내용은 HTTP 프로토콜의 거시적인 작동을 간략하게 소개합니다. 다음은 HTTP 프로토콜의 내부 작동 과정을 소개합니다.

먼저, 그림 2-4와 같이 HTTP 프로토콜을 기반으로 하는 클라이언트/서버 모델의 정보 교환 프로세스를 간략하게 소개하자면, 연결 설정, 요청 정보 전송의 4가지 프로세스로 나누어진다. , 응답 정보 전송 및 연결 종료.

그림 2-4

WWW에서 "클라이언트"와 "서버"는 특정 연결 중에만 존재하는 상대적인 개념입니다. 즉, 클라이언트는 특정 연결 내에서 존재할 수 있습니다. 다른 연결에서 서버 역할을 합니다. WWW 서버가 실행 중일 때 항상 TCP80 포트(WWW의 기본 포트)에서 수신 대기하며 연결이 나타날 때까지 기다립니다.

다음으로 HTTP 프로토콜 하의 클라이언트/서버 모드에서 정보 교환 구현에 대해 논의합니다. 1. 연결을 설정합니다. 소켓을 신청하여 연결이 설정됩니다. 클라이언트는 소켓을 열고 이를 포트에 바인딩합니다. 성공하면 가상 파일을 만드는 것과 같습니다. 미래에는 가상 파일에 데이터를 기록하고 네트워크를 통해 전송할 수 있습니다.

2. 요청 보내기

연결을 연 후 클라이언트는 요청 작업을 완료하기 위해 서버의 체류 포트에 요청 메시지를 보냅니다.

HTTP/1.0 요청 메시지의 형식은 다음과 같습니다.

요청 메시지 = 요청 라인(일반 정보 | 요청 헤더 | 엔터티 헤더) CRLF [엔티티 콘텐츠]

요청 라인 = 메소드 요청 URL HTTP 버전 번호 CRLF

메소드 = GET|HEAD|POST|확장 메소드

U R L = 프로토콜 이름 + 호스트 이름 + 디렉토리 및 파일 이름

p>

요청 라인의 메소드는 지정된 리소스에 대해 수행되어야 하는 작업을 설명합니다. 일반적으로 사용되는 메소드는 GET, HEAD 및 POST입니다. 요청 객체마다 GET 결과가 다릅니다. 해당 관계는 다음과 같습니다.

객체 GET 결과

파일 내용

프로그램 실행 결과

데이터베이스 쿼리 쿼리 결과

HEAD - 개체 자체가 아닌 개체에 대한 메타 정보를 조회하도록 서버에 요청합니다.

POST - 클라이언트에서 서버로 데이터를 전송합니다. POST 메서드는 서버와 CGI의 추가 처리가 필요할 때 사용됩니다. POST는 주로 CGI 프로그램에서 처리할 HTML 텍스트의 FORM 내용을 보내는 데 사용됩니다.

요청의 예는 다음과 같습니다:

GETneorking.zju.edu/zju/indexHTTP/1.0

헤더 정보는 메타 정보라고도 하며, 정보 중 메타정보를 이용하여 조건부 요청이나 응답을 구현할 수 있다.

요청 헤더 - 주로 사용자가 수용할 수 있는 데이터 유형, 압축 방법 및 언어를 포함하여 이 요청을 해석하는 방법을 서버에 알려줍니다.

엔터티 헤더 - 엔터티 정보 유형, 길이, 압축 방법, 마지막 수정 시간, 데이터 유효 기간 등

엔터티 - 요청 또는 응답 개체 자체입니다.

3. 응답 보내기

서버는 클라이언트의 요청을 처리한 후 클라이언트에 응답 메시지를 보냅니다.

HTTP/1.0의 응답 메시지 형식은 다음과 같습니다.

응답 메시지 = 상태 줄(일반 정보 헤더 | 응답 헤더 | 엔터티 헤더) CRLF [엔티티 내용]

상태 줄 = HTTP 버전 번호 상태 코드 이유 설명

상태 코드는 응답 유형을 나타냅니다.

1×× 예약됨

2××는 요청이 성공적으로 수신되었습니다.

3×× 요청을 완료하려면 클라이언트가 요청을 더 구체화해야 합니다.

4×× 클라이언트 오류

5×× 서버 오류

응답 헤더 정보에는 서비스 프로그램 이름, 요청한 URL에 인증이 필요함을 클라이언트에 알리는 정보, 요청한 리소스를 사용할 수 있는 시기 등이 포함됩니다.

4. 연결 닫기

클라이언트와 서버 모두 소켓을 닫아 TCP/IP 대화를 종료할 수 있습니다.