Http 프로토콜과 TCP 프로토콜의 차이점은 무엇입니까?-PHP 튜토리얼-php.cn

TCP 프로토콜은 전송 계층에 해당하지만 HTTP 프로토콜은 애플리케이션 계층에 해당합니다. 본질적으로 둘은 비교할 수 없습니다. Http 프로토콜은 TCP 프로토콜을 기반으로 하며, 브라우저가 서버에서 웹 페이지 데이터를 가져와야 할 경우 Http 요청을 발행합니다. Http는 TCP를 통해 서버에 대한 연결 채널을 설정합니다. 이 요청에 필요한 데이터가 완료되면 Http는 즉시 TCP 연결을 끊습니다. 이 프로세스는 매우 짧습니다. 따라서 HTTP 연결은 짧은 연결이자 상태 비저장 연결입니다. 소위 상태 비저장이란 브라우저가 서버에 대한 요청을 시작할 때마다 연결을 거치지 않고 매번 새로운 연결을 설정한다는 의미입니다. 연결인 경우 서버 프로세스는 연결을 유지하고 일부 정보 상태를 메모리에 기억할 수 있습니다. 각 요청이 끝나면 연결이 닫히고 해당 콘텐츠가 해제되므로 상태가 기억되지 않고 상태 비저장 연결이 됩니다.

시간이 지날수록 HTML 페이지는 더욱 복잡해지고, 많은 그림이 삽입될 수 있습니다. 이때 그림에 액세스할 때마다 TCP 연결을 설정하는 것은 비효율적입니다. 따라서 낮은 효율성 문제를 해결하기 위해 Keep-Alive가 제안되었습니다. HTTP/1.1부터는 연결 기능을 유지하기 위해 기본적으로 Keep-Alive가 활성화됩니다. 간단히 말해서 웹 페이지가 열릴 때 클라이언트와 서버 간에 HTTP 데이터를 전송하는 데 사용되는 TCP 연결이 닫히지 않습니다. 클라이언트 이 서버의 웹페이지를 다시 방문하면 설정된 연결을 계속 사용하게 됩니다. 연결 유지는 연결을 영구적으로 유지하지 않으며 다른 서버 소프트웨어(예: Apache)에서 설정할 수 있습니다. 여기에서는 일정 시간 동안 TCP 연결이 유지되지만 이 시간은 제한되어 있으며 해당 시점에서는 여전히 닫혀 있으므로 각 연결이 완료된 후에도 닫히는 것으로 간주합니다. 나중에 Session을 통해 쿠키 및 기타 관련 기술도 일부 사용자의 상태를 유지할 수 있습니다. 그러나 매번 하나의 연결을 사용하며 여전히 상태 비저장 연결입니다.
　예전에는 헷갈리면 참을 수 없는 컨셉이 있었어요. 이것이 Http가 상태 비저장 짧은 연결이고 TCP가 상태 저장 긴 연결인 이유입니까? HTTP는 TCP를 기반으로 하지 않습니까? 왜 여전히 짧은 연결이 될 수 있습니까? 이제 Http는 각 요청이 완료된 후 TCP 연결을 닫으므로 짧은 연결이라는 것을 이해합니다. 소켓 프로그래밍을 통해 직접 TCP 프로토콜을 사용하는 경우, 코드 영역을 통해 연결을 열고 닫을 시기를 제어할 수 있기 때문에 코드를 통해 연결을 닫지 않는 한 연결은 클라이언트와 클라이언트의 프로세스에 있게 됩니다. 항상 존재하며 해당 상태 데이터는 항상 저장됩니다.
　 C#에는 소켓이 있습니다. 실제로 소켓은 TCP/IP 프로토콜을 캡슐화한 것입니다. 소켓 자체는 프로토콜이 아니라 호출 인터페이스(API)입니다. 소켓의 출현은 프로그래머가 TCP/IP 프로토콜 스택을 더 쉽게 사용할 수 있도록 해줄 뿐입니다. 이는 TCP/IP 프로토콜의 추상화이므로 생성, 수신, 연결과 같은 우리가 알고 있는 가장 기본적인 기능 인터페이스 중 일부를 형성합니다. 수락하고 보내기, 읽기 및 쓰기 등.

더 생생한 설명: HTTP는 데이터를 캡슐화하거나 표시하는 특정 형식을 제공하는 자동차이고, 소켓은 네트워크 통신 기능을 제공하는 엔진입니다. C# 프로그래밍 관점에서 편의상 이미 제조된 자동차 Http를 직접 선택하여 서버와 상호 작용할 수 있습니다. 그러나 환경적인 요인이나 기타 사용자 정의된 요청으로 인해 TCP 프로토콜을 사용해야 하는 경우도 있습니다. 이 경우 소켓 프로그래밍을 사용한 후 얻은 데이터를 직접 처리해야 합니다. 기존 엔진을 사용하여 트럭을 만들고 서버와 상호 작용하는 것과 같습니다.

　 HTTP/1.0과 HTTP/1.1은 모두 기본 전송 프로토콜로 TCP를 사용합니다. HTTP 클라이언트는 먼저 서버와의 TCP 연결 설정을 시작합니다. 연결이 설정되면 브라우저 프로세스와 서버 프로세스는 해당 소켓을 통해 TCP에 액세스할 수 있습니다. 앞서 언급했듯이 클라이언트 소켓은 클라이언트 프로세스와 TCP 연결 사이의 "문"이고, 서버 측 소켓은 서버 프로세스와 동일한 TCP 연결 사이의 "문"입니다. 클라이언트는 HTTP 요청 메시지를 자체 소켓으로 보내고 자체 소켓에서 HTTP 응답 메시지를 받습니다. 마찬가지로 서버는 자체 소켓에서 HTTP 요청 메시지를 수신하고 자체 소켓으로 HTTP 응답 메시지를 보냅니다. 클라이언트나 서버가 해당 소켓으로 메시지를 보내면 메시지는 완전히 TCP의 제어를 받게 됩니다. TCP는 HTTP에 안정적인 데이터 전송 서비스를 제공합니다. 이는 클라이언트가 보낸 모든 HTTP 요청 메시지가 결국 손실 없이 서버에 도달하고, 서버에서 보낸 모든 HTTP 응답 메시지가 결국 손실 없이 클라이언트에 도달한다는 것을 의미합니다.
　C# 코드는 TCP 프로토콜을 사용하여 원격 데이터베이스에 연결합니다. 새로운 연결이 생성될 때마다 Connection.open은 TCP 연결을 엽니다. Connection.Close가 호출되면 연결이 닫힙니다. FTP의 맨 아래 계층도 TCP이지만 장기 연결입니다. 대용량 파일을 전송하는 것이 더 빠릅니다. 특정 시나리오에 따라 다릅니다. 서버 측에서는 프로그램이 긴 연결 방식을 채택하는 경우 동시에 서버에 대한 연결 수를 제어하여 동시에 여러 연결을 방지할 수 있습니다. 그러나 짧은 연결을 사용하면 동시에 서버에 대한 연결 수를 제어할 수 없으며, 이는 동시에 많은 수의 연결 요청을 처리할 수 있다는 장점도 있습니다. 단, 연결 요청 수가 너무 많으면 서버가 작동하지 않을 수 있습니다.
　WebService는 연결이 필요하지 않으며 1초에 최소 수만/수십만 개의 요청을 지원할 수 있으며 각 요청은 해제되며 여유 메모리 소비가 없습니다. 일반적으로 동시 연결 수에 제한이 없다는 점이 장점입니다. Message Queue는 연결을 설정해야 하며 수천 개의 연결을 지원하는 것은 매우 어렵습니다. 각 연결은 데이터를 요청하지 않더라도 메모리에서 일정량의 공간을 차지하기 때문입니다. 일반적으로 최대 16개의 동시 연결이 가능한 SQL Server 데이터베이스 서버와 같은 제한 사항이 있습니다.

　　Http 프로토콜은 지정된 포트인 80을 통과해야 하므로 일반 컴퓨터에서는 이 포트가 제한되지 않으므로 모든 컴퓨터의 방화벽을 성공적으로 통과할 수 있습니다. 소켓 프로그래밍을 사용하는 경우 특정 포트를 직접 지정해야 합니다. 그러면 특정 환경에서 이 포트가 비활성화되어 방화벽을 통과하지 못할 가능성이 높습니다. IIS는 포트 80을 사용합니다. 이는 이 프로그램이 이 포트를 수신하고 있음을 의미합니다. 누군가가 이 포트에 연결을 설정하려는 것을 발견하면 응답하고 연결을 설정합니다. 여기에 언급된 연결은 모두 짧은 연결입니다. 따라서 서버의 URL에 대한 요청은 포트 80을 통해 웹사이트 프로그램으로 전송됩니다. 그런 다음 클라이언트 브라우저는 이 포트를 통해 이를 보냅니다.

HTTP는 애플리케이션 계층에 속하는 객체 지향 프로토콜로, 간단하고 빠른 방식으로 인해 분산형 하이퍼미디어 정보 시스템에 적합합니다. 1990년에 제안되었으며 수년간의 사용과 개발을 거쳐 지속적으로 개선되고 확장되었습니다. 현재 WWW에서는 HTTP/1.0의 6번째 버전이 사용되고 있으며, HTTP/1.1의 표준화 작업이 진행 중이며, HTTP-NG(다음) HTTP 생성) 제안이 작성되었습니다.
HTTP 프로토콜의 주요 기능은 다음과 같이 요약됩니다.
1. 클라이언트/서버 모드를 지원합니다.
2. 간단하고 빠릅니다. 클라이언트가 서버에 서비스를 요청할 때 요청 방법과 경로만 전송하면 됩니다. 일반적으로 사용되는 요청 방법은 GET, HEAD 및 POST입니다. 각 방법은 클라이언트와 서버 간의 다양한 연결 유형을 지정합니다. HTTP 프로토콜의 단순성으로 인해 HTTP 서버의 프로그램 크기는 작고 통신 속도는 매우 빠릅니다.
3. 유연성: HTTP는 모든 유형의 데이터 개체 전송을 허용합니다. 전송되는 유형은 Content-Type으로 표시됩니다.
4. 연결 없음: 연결 없음의 의미는 각 연결이 하나의 요청만 처리하도록 제한하는 것입니다. 서버는 클라이언트의 요청을 처리하고 클라이언트의 응답을 받은 후 연결을 끊습니다. 이 방법을 사용하면 전송 시간이 절약됩니다.
5. 상태 비저장: HTTP 프로토콜은 상태 비저장 프로토콜입니다. Stateless는 프로토콜에 트랜잭션 처리를 위한 메모리 기능이 없음을 의미합니다. 상태가 없다는 것은 후속 처리에 이전 정보가 필요한 경우 다시 전송해야 하므로 연결당 전송되는 데이터 양이 증가할 수 있음을 의미합니다. 반면에 서버는 이전 정보가 필요하지 않을 때 더 빠르게 응답합니다.

1. HTTP 프로토콜에 대한 자세한 설명 - URL

http(Hypertext Transfer Protocol)는 요청 및 응답 모드를 기반으로 하는 상태 비저장 애플리케이션 계층 프로토콜이며, 종종 TCP를 기반으로 합니다. 연결 방법: HTTP 1.1 버전은 지속적인 연결 메커니즘을 제공합니다. 대부분의 웹 개발은 HTTP 프로토콜을 기반으로 구축된 웹 애플리케이션입니다.

HTTP URL(URL은 리소스를 찾는 데 충분한 정보가 포함된 특수한 유형의 URI입니다)의 형식은 다음과 같습니다.
http://host[":"port][abs_path]
http는 네트워크 리소스를 나타냅니다. HTTP 프로토콜을 통해 찾을 수 있습니다. 호스트는 합법적인 인터넷 호스트 도메인 이름 또는 IP 주소를 나타냅니다. 포트가 비어 있으면 기본 포트 80이 사용됩니다. URL abs_path에 제공되지 않은 경우 요청 URI로 사용되는 경우 일반적으로 브라우저가 자동으로 이 작업을 완료합니다.
예:
1. 입력: www.guet.edu.cn
브라우저가 자동으로 다음으로 변환됩니다. http://www.guet.edu.cn/
2. /index.jsp

2. HTTP 프로토콜에 대한 자세한 설명 요청

http 요청은 요청 라인, 메시지 헤더, 요청 본문

세 부분으로 구성됩니다. 요청 행은 공백으로 구분된 메소드 기호로 시작하고 그 뒤에 요청된 URI 및 프로토콜 버전이 옵니다. 메소드 요청-URI HTTP-버전 CRLF
여기서 메소드는 요청 메소드를 나타냅니다. 리소스 식별자, HTTP -Version은 요청된 HTTP 프로토콜 버전을 나타냅니다. CRLF는 캐리지 리턴 및 줄 바꿈을 나타냅니다(후행 CRLF 제외, 별도의 CR 또는 LF 문자는 허용되지 않음).

요청 방법에는 여러 가지가 있습니다(모든 방법은 대문자임). 각 방법에 대한 설명은 다음과 같습니다.
GET Request-URI로 식별된 리소스를 얻기 위한 요청
POST Request로 식별된 리소스 뒤에 새 데이터를 추가합니다. -URI
HEAD Request-URI로 식별된 리소스의 응답 메시지 헤더를 가져오도록 요청
PUT 서버에 리소스를 저장하도록 요청하고 Request-URI를 식별자로 사용
DELETE 서버에 Request-URI로 식별된 리소스를 삭제하도록 요청
TRACE 주로 테스트 또는 진단을 위해 수신된 요청 정보를 서버에 다시 보내도록 요청합니다.
CONNECT 향후 사용을 위해 예약됩니다.
OPTIONS 서버 성능을 쿼리하거나 리소스와 관련된 옵션 및 요구 사항을 쿼리하는 요청
응용 사례:
GET 메소드: 브라우저의 주소 표시줄에 URL을 입력하는 방법 웹 페이지에 접근할 때 브라우저는 GET 메소드를 사용하여 서버에서 자원을 얻습니다. 예: GET /form.html HTTP/1.1 (CRLF)

The POST 방법은 요청된 서버가 요청에 첨부된 데이터를 수락해야 하며 양식을 제출하는 데 자주 사용됩니다.
예:POST /reg.jsp HTTP/ (CRLF)
Accept:image/gif,image/x-xbit,... (CRLF)
...
HOST:www.guet.edu.cn (CRLF)
Content-Length:22 (CRLF)
Connection:Keep-Alive (CRLF)
Cache-Control:no-cache (CRLF)
(CRLF) //이 CRLF는 메시지 헤더가 종료되었음을 나타냅니다. message header
user =jeffrey&pwd=1234 //다음 줄은 제출된 데이터입니다

HEAD 메서드는 GET 메서드와 거의 동일합니다. HEAD 요청의 응답 부분의 경우 HTTP 헤더에 포함된 정보는 다음과 같습니다. GET 요청과 동일합니다. 이 방법을 사용하면 전체 리소스 내용을 전송하지 않고도 Request-URI로 식별되는 리소스에 대한 정보를 얻을 수 있다. 이 방법은 하이퍼링크의 유효성, 액세스 가능 여부, 최근 업데이트되었는지 여부를 테스트하는 데 자주 사용됩니다.
2. 요청 헤더 설명은 나중에
3. 요청 본문(생략)

3. HTTP 프로토콜에 대한 자세한 설명이 포함된 응답 장

서버는 요청 메시지를 수신하고 해석한 후 HTTP 응답 메시지를 반환합니다. .

HTTP 응답도 상태 줄, 메시지 헤더, 응답 본문의 세 부분으로 구성됩니다.
1 상태 줄 형식은 다음과 같습니다.
HTTP-버전 상태-코드 이유-구문 CRLF
그 중 HTTP-버전 서버 HTTP를 나타냅니다. 프로토콜 버전은 서버가 보낸 응답 상태 코드를 나타냅니다. Reason-Phrase는 상태 코드의 텍스트 설명을 나타냅니다.
상태 코드는 세 자리 숫자로 구성되며 응답 범주를 정의하며 5개의 가능한 값이 있습니다.
1xx: 표시 정보--요청이 수신되었으며 계속 처리됨을 나타냅니다.
2xx: 성공--을 나타냅니다. 요청이 처리되었음을 나타냅니다. 성공적으로 수신, 이해, 수락되었습니다
3xx: 리디렉션-요청을 완료하려면 추가 작업을 수행해야 합니다
4xx: 클라이언트 측 오류-요청에 구문 오류가 있거나 요청을 이행할 수 없습니다
5xx : 서버 측 오류--서버가 이를 이행하지 못했습니다. 법적 요청
공통 상태 코드, 상태 설명, 설명:
200 OK //클라이언트 요청이 성공했습니다
400 잘못된 요청 //클라이언트 요청에 구문 오류가 있어 처리할 수 없습니다. 서버가 이해함
401 Unauthorized //요청이 승인되지 않았습니다. 이 상태 코드는 WWW-Authenticate 헤더 필드와 함께 사용해야 합니다.
403 Forbidden //서버가 요청을 받았지만 서비스 제공을 거부했습니다
404 Not Found //요청한 리소스가 존재하지 않습니다. 예: 잘못된 URL이 입력되었습니다
500 내부 서버 오류 / /서버에서 예상치 못한 오류가 발생했습니다
503 서버를 사용할 수 없습니다. //서버가 현재 클라이언트의 요청을 처리할 수 없으며 다음으로 돌아갈 수 있습니다. 일정 시간이 지나면 정상
eg: HTTP/1.1 200 OK (CRLF)

2. 응답 헤더는 나중에 설명합니다

3. 응답 본문은 서버에서 반환한 리소스의 내용입니다

4. HTTP 프로토콜 상세 설명 - 메시지 헤더

HTTP 메시지는 클라이언트-서버 요청과 서버-클라이언트 응답으로 구성됩니다. 요청 메시지와 응답 메시지 모두 시작 라인(요청 메시지의 경우 시작 라인은 요청 라인, 응답 메시지의 경우 시작 라인은 상태 라인), 메시지 헤더(선택 사항), 빈 라인(CRLF만 해당)으로 구성됩니다. 행), 메시지 본문(선택 사항) 구성.

HTTP 메시지 헤더에는 일반 헤더, 요청 헤더, 응답 헤더 및 엔터티 헤더가 포함됩니다.
각 헤더 필드는 이름 + ":" + 공백 + 값으로 구성됩니다. 메시지 헤더 필드의 이름은 대소문자를 구분하지 않습니다.

1. 일반 헤더
일반 헤더에는 모든 요청 및 응답 메시지에 사용되지만 전송된 엔터티에는 사용되지 않고 전송된 메시지에만 사용되는 몇 가지 헤더 필드가 있습니다.
예:
Cache-Control은 캐시 명령을 지정하는 데 사용됩니다. 캐시 명령은 단방향(응답에 나타나는 캐시 명령이 요청에 나타나지 않을 수 있음)이며 독립적입니다(한 메시지의 캐시 명령은 영향을 미치지 않습니다). 다른 메시지) 처리를 위한 캐싱 메커니즘), HTTP 1.0에서 사용되는 유사한 헤더 필드는 Pragma입니다.
요청 시 캐싱 지시문에는 no-cache(요청 또는 응답 메시지를 캐시할 수 없음을 나타내는 데 사용됨), no-store, max-age, max-stale, min-fresh, only-if-cached가 포함됩니다. 지침에는 public, private, no-cache, no-store, no-transform, must-revalidate, Proxy-revalidate, max-age, s-maxage가 포함됩니다.
예: IE 브라우저(클라이언트)에 캐시하지 않도록 지시하려면 페이지에서 서버측 JSP 프로그램은 다음과 같이 작성할 수 있습니다: response.sehHeader("Cache-Control","no-cache");
//response.setHeader("Pragma","no-cache"); 이 함수는 위 코드와 동일하며 일반적으로 둘 다 // 함께 사용됩니다.
이 코드는 전송된 응답 메시지에 일반 헤더 필드를 설정합니다. Cache-Control: no-cache

Date 일반 헤더 필드는 날짜를 나타내고 메시지가 생성된 시간

Connection 일반 헤더 필드를 사용하면 연결별 옵션을 보낼 수 있습니다. 예를 들어, 연결이 계속되도록 지정하거나 "close" 옵션을 지정하여 응답이 완료된 후 연결을 닫도록 서버에 알립니다

2. 요청 헤더
요청 헤더를 사용하면 클라이언트가 요청에 대한 추가 정보와 클라이언트 자신의 정보를 서버에 전달할 수 있습니다.
일반적으로 사용되는 요청 헤더
Accept
Accept 요청 헤더 필드는 클라이언트가 수락하는 정보 유형을 지정하는 데 사용됩니다. 예: Accept: image/gif는 클라이언트가 GIF 이미지 형식의 리소스를 허용하기를 원함을 나타냅니다. Accept: text/html은 클라이언트가 html 텍스트를 허용하기를 원함을 나타냅니다.
Accept-Charset
Accept-Charset 요청 헤더 필드는 클라이언트가 허용하는 문자 집합을 지정하는 데 사용됩니다. 예: Accept-Charset:iso-8859-1, gb2312 이 필드가 요청 메시지에 설정되지 않은 경우 기본값은 모든 문자 집합이 허용되는 것입니다.
Accept-Encoding
Accept-Encoding 요청 헤더 필드는 Accept와 유사하지만 허용되는 콘텐츠 인코딩을 지정하는 데 사용됩니다. 예: Accept-Encoding:gzip.deflate 요청 메시지에 이 도메인이 설정되지 않은 경우 서버는 클라이언트가 다양한 콘텐츠 인코딩을 수락할 수 있다고 가정합니다.
Accept-Language
Accept-Language 요청 헤더 필드는 Accept와 유사하지만 자연어를 지정하는 데 사용됩니다. 예: Accept-Language:zh-cn. 요청 메시지에 이 헤더 필드가 설정되어 있지 않으면 서버는 클라이언트가 다양한 언어를 수락할 수 있다고 가정합니다.
Authorization
Authorization 요청 헤더 필드는 주로 클라이언트가 특정 리소스를 볼 수 있는 권한이 있음을 증명하는 데 사용됩니다. 브라우저가 페이지에 접근하여 서버로부터 401(Unauthorized) 응답 코드를 수신하면 Authorization 요청 헤더 필드가 포함된 요청을 보내 서버에 이를 확인하도록 요청할 수 있습니다.
Host(이 헤더 필드는 요청을 보낼 때 필요합니다.)
Host 요청 헤더 필드는 주로 요청된 리소스의 인터넷 호스트와 포트 번호를 지정하는 데 사용됩니다. 일반적으로 HTTP URL에서 추출됩니다. 예:
브라우저를 사용합니다. 입력: http://www.guet.edu.cn/index.html
브라우저에서 보낸 요청 메시지에는 다음과 같은 호스트 요청 헤더 필드가 포함됩니다.
호스트: www.guet.cn.
여기에서는 기본 포트 번호 80이 사용됩니다. 포트 번호를 지정하면 다음과 같습니다. 호스트: www.guet.edu.cn: 포트 번호를 지정하세요
User-Agent
온라인 포럼에서 운영 체제의 이름과 버전, 사용 중인 브라우저의 이름과 버전이 나열된 환영 정보를 자주 볼 수 있습니다. 정보는 User-Agent 요청 헤더 필드에서 가져옵니다. User-Agent 요청 헤더 필드를 통해 클라이언트는 서버에 운영 체제, 브라우저 및 기타 속성을 알릴 수 있습니다. 그러나 이 헤더 필드는 필요하지 않습니다. 브라우저를 직접 작성하고 User-Agent 요청 헤더 필드를 사용하지 않으면 서버가 우리 정보를 알 수 없습니다.
요청 헤더 예:
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel, application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 2007년 1월 11:21:25 GMT (CRLF)
If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
User-Agent:Mozilla/4.0(호환;MSIE6.0;Windows NT 5.0) (CRLF)
Host: www.guet.edu.cn (CRLF)
Connection: Keep-Alive (CRLF)
(CRLF)

3 응답 헤더를 사용하면 서버가 전달할 수 없는 정보를 전달할 수 있습니다. 상태 줄에 추가 응답 정보, 서버에 대한 정보, Request-URI에 의해 식별된 리소스에 대한 다음 액세스에 대한 정보가 표시됩니다.
일반적으로 사용되는 응답 헤더
Location
위치 응답 헤더 필드는 수신자를 새 위치로 리디렉션하는 데 사용됩니다. 위치 응답 헤더 필드는 도메인 이름을 변경할 때 자주 사용됩니다.
Server
서버 응답 헤더 필드에는 서버가 요청을 처리하는 데 사용하는 소프트웨어에 대한 정보가 포함되어 있습니다. User-Agent 요청 헤더 필드에 해당합니다. 다음은
Server 응답 헤더 필드의 예입니다.
Server: Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate 응답 헤더 필드는 401(승인되지 않음) 응답 메시지에 포함되어야 하며, 클라이언트는 401 응답을 받습니다. 메시지를 전송하고 Authorization 헤더 필드를 보내 서버에 확인을 요청하면 서버 응답 헤더에 이 헤더 필드가 포함됩니다.
예: WWW-Authenticate:Basic realm="Basic Auth Test!" //서버가 리소스 요청을 위해 기본 확인 메커니즘을 사용하는 것을 볼 수 있습니다.

4. 엔터티 헤더
요청 메시지와 응답 메시지 모두 엔터티를 전송할 수 있습니다. 엔터티는 엔터티 헤더 필드와 엔터티 본문으로 구성됩니다. 그러나 엔터티 헤더 필드와 엔터티 본문을 함께 보내야 한다는 의미는 아닙니다. 엔터티 헤더는 엔터티 본문(예: 엔터티 본문의 존재 여부)과 요청에 의해 식별되는 리소스에 대한 메타 정보를 정의합니다.
일반적으로 사용되는 엔터티 헤더
Content-Encoding
Content-Encoding 엔터티 헤더 필드는 미디어 유형의 수정자로 사용됩니다. 해당 값은 엔터티 본문에 적용된 추가 콘텐츠의 인코딩을 나타냅니다. 따라서 Content-Type 헤더 필드는 참조된 미디어 유형은 해당 디코딩 메커니즘을 사용해야 합니다. Content-Encoding은 문서의 압축 방법을 기록하는 데 사용됩니다. 예: Content-Encoding: gzip
Content-Language
Content-Language 엔터티 헤더 필드는 리소스에서 사용되는 자연 언어를 설명합니다. 이 필드가 설정되지 않으면 엔터티 콘텐츠가 모든 언어로 독자에게 제공되는 것으로 가정됩니다. 예: Content-Language:da
Content-Length
Content-Length 엔터티 헤더 필드는 엔터티 본문의 길이를 나타내는 데 사용되며 바이트 단위로 저장된 십진수로 표시됩니다.
Content-Type
Content-Type 엔터티 헤더 필드 용어는 수신자에게 전송되는 엔터티 본문의 미디어 유형을 나타냅니다. 예:
Content-Type: text/html; charset=ISO-8859-1
Content-Type: text/html; charset=GB2312
Last-Modified
Last-Modified 엔터티 헤더 필드는 마지막으로 수정된 날짜를 나타내는 데 사용됩니다. 자원과 시간.
Expires
Expires 엔터티 헤더 필드는 응답이 만료되는 날짜와 시간을 제공합니다. 프록시 서버나 브라우저가 일정 시간 후에 캐시에 있는 페이지를 업데이트할 수 있도록(이전에 방문한 페이지에 다시 액세스할 때 캐시에서 직접 로드하여 응답 시간을 단축하고 서버 부하를 줄임) 다음을 수행할 수 있습니다. Expires 엔터티 헤더 필드를 사용하여 페이지 만료 시간을 지정합니다. 예: 만료: Thu, 15 Sep 2006 16:23:12 GMT
HTTP 1.1의 클라이언트와 캐시는 다른 불법 날짜 형식(0 포함)을 만료된 것으로 처리해야 합니다. 예: 브라우저가 페이지를 캐싱하는 것을 방지하기 위해 Expires 엔터티 헤더 필드를 사용하고 이를 0으로 설정할 수도 있습니다. jsp의 프로그램은 다음과 같습니다: response.setDateHeader("Expires","0");

5. Telnet을 사용하여 http 프로토콜의 통신 프로세스를 관찰합니다.

실험의 목적과 원리: MS의 Telnet 도구를 사용하여 http 요청 정보를 수동으로 입력하여 서버에 요청을 보냅니다. 서버는 요청을 수신, 해석 및 수락하고 응답을 반환하며 응답은 텔넷 창에 표시되므로 http 프로토콜의 통신 프로세스에 대한 지각적 이해가 깊어집니다.

실험 단계:

1. Telnet 열기1.1 Telnet 열기
Run-->cmd-->telnet

1.2 Telnet 에코 기능 켜기localecho 설정

2. 서버에 연결하고 요청 보내기2.1 open
www.guet.edu.cn 80 //포트 번호는 생략할 수 없습니다

HEAD /index.asp HTTP/1.0 호스트:www. guet.edu.cn

/*계림전자 홈페이지 콘텐츠를 요청하기 위해 요청 방법을 변경할 수 있으며, 다음과 같이 메시지를 입력하세요*/
open
www.guet.edu.cn 80
GET /index. asp HTTP/1.0 //리소스 내용 요청
Host:www.guet.edu.cn

2.2 open www.sina.com.cn 80 //명령 프롬프트에서 직접 Telnet 입력 www.sina.com.cn 80 HEAD /index.asp HTTP/1.0
Host:www.sina.com.cn

3 실험 결과:

3.1 정보 2.1을 요청하여 얻은 응답은 다음과 같습니다. > 51 GMT

연결: Keep-Alive -유형: text/htmlExpries: Thu,08 Mar 2007 07:16:51 GMT
Set-Cookie : ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKAJEOIMMH; path=/
Cache-control: private

//리소스 내용 생략됨

3.2 정보 2.2를 요청하여 얻은 응답은 다음과 같습니다.

HTTP/1.0 404 찾을 수 없음 // 요청 실패

날짜: 2007년 3월 8일 목요일 07:50:50 GMT 서버: Apache/2.0.54 최종 수정: 2006년 11월 30일 목요일 11:35:41 GMTETag: "6277a-415 -e7c76980"

Accept-Ranges: bytes

X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remixVary: Accept-Encoding
Content-Type: text/html
X-Cache: zjm152-78의 MISS. sina.com.cn
Via: 1.0 zjm152-78.sina.com.cn:80
사항: 1. 입력 오류가 있는 경우 요청이 성공하지 않습니다.
2. 헤더 필드는 대소문자를 구분하지 않습니다.
3. HTTP 프로토콜에 대해 자세히 알아보려면 RFC2616을 보고
http://www.letf.org/rfc

에서 파일을 찾으세요.程 4. 개발 배경 프로그램은 HTTP 프로토콜을 마스터해야 합니다

HTTP 프로토콜 관련 기술 보충

1. 기본 사항:
고급 프로토콜에는 파일 전송 프로토콜 FTP, 이메일 전송 프로토콜 SMTP, 도메인 이름 시스템 서비스 DNS, 네트워크 뉴스 전송 프로토콜 NNTP 및 HTTP 프로토콜 등이 포함됩니다.
중개자에는 세 가지 유형이 있습니다: 프록시, 게이트웨이) 및 채널(터널)인 프록시는 URI의 절대 형식에 따라 요청을 수락하고 메시지의 전체 또는 일부를 다시 작성한 후 URI 식별자를 통해 형식화된 요청을 서버에 보냅니다. 게이트웨이는 다른 서버 위의 계층 역할을 하며 필요한 경우 요청을 기본 서버 프로토콜로 변환할 수 있는 수신 프록시입니다. 채널은 메시지를 변경하지 않는 두 연결 간의 중계 지점 역할을 합니다. 채널은 통신이 중개자(예: 방화벽 등)를 통과해야 하거나 중개자가 메시지 내용을 식별할 수 없는 경우에 자주 사용됩니다.
프록시: 다른 클라이언트에 대한 요청을 설정하기 위해 서버 또는 클라이언트 역할을 할 수 있는 중간 프로그램입니다. 요청은 가능한 번역을 통해 내부적으로 또는 다른 서버를 통해 전달됩니다. 프록시는 요청 메시지를 보내기 전에 요청 메시지를 해석하고 가능하면 다시 작성해야 합니다. 프록시는 방화벽을 통해 클라이언트를 위한 포털 역할을 하는 경우가 많습니다. 프록시는 사용자 에이전트에 의해 완료되지 않은 프로토콜을 통한 요청을 처리하는 도우미 응용 프로그램 역할도 할 수 있습니다.
게이트웨이: 다른 서버를 중개하는 역할을 하는 서버입니다. 프록시와 달리 게이트웨이는 요청된 리소스에 대한 원본 서버인 것처럼 요청을 수락합니다. 요청 클라이언트는 자신이 게이트웨이를 처리하고 있다는 사실을 인식하지 못합니다.
게이트웨이는 방화벽을 통해 서버 측 포털 역할을 하는 경우가 많습니다. 게이트웨이는 HTTP가 아닌 시스템에 저장된 리소스에 액세스하기 위한 프로토콜 변환기 역할도 할 수 있습니다.
채널(터널): 두 연결 사이를 중계하는 역할을 하는 중개 프로그램입니다. 일단 활성화되면 채널은 HTTP 요청에 의해 시작될 수 있지만 HTTP 통신에 속하는 것으로 간주되지 않습니다. 릴레이된 연결의 양쪽 끝이 닫히면 채널이 사라집니다. 채널은 포털이 반드시 존재해야 하거나 중개자가 릴레이된 트래픽을 해석할 수 없는 경우에 자주 사용됩니다.

2. 프로토콜 분석의 장점 - HTTP 분석기는 네트워크 공격을 탐지합니다.
고급 프로토콜을 모듈식으로 분석하고 처리하는 것이 향후 침입 탐지의 방향이 될 것입니다.
일반적으로 사용되는 HTTP의 포트 80, 3128, 8080과 해당 프록시는 네트워크 섹션의 포트 태그로 지정됩니다

3. HTTP 프로토콜 콘텐츠 길이 제한 취약점으로 인해 서비스 거부 공격이 발생합니다.
POST 방법을 사용할 때 다음을 설정할 수 있습니다. ContentLenth는 전송해야 하는 콘텐츠의 데이터 길이(예: ContentLenth:999999999)를 정의하며, 전송이 완료되기 전에는 메모리가 해제되지 않습니다. 공격자는 이 결함을 이용하여 가비지 데이터를 웹 서버에 지속적으로 보낼 수 있습니다. 웹 서버에 메모리가 부족합니다. 이 공격 방법은 기본적으로 흔적을 남기지 않습니다.
http://www.cnpaf.net/Class/HTTP/0532918532667330.html

4. HTTP 프로토콜의 특성을 이용하여 서비스 거부 공격을 수행하는 몇 가지 아이디어
서버가 위조된 TCP 연결 요청을 처리 중입니다. 공격자는 정상적인 요청에 대해 클라이언트에 주의를 기울일 시간이 없습니다(결국 클라이언트의 정상적인 요청 비율은 매우 낮습니다). 이때 일반 클라이언트의 관점에서 보면 서버가 응답을 잃는 상황이라고 합니다. : 서버가 SYNFlood 공격(SYN 플러드 공격)을 받고 있습니다.
Smurf, TearDrop 등은 ICMP 메시지를 사용하여 Flood 및 IP 조각화 공격을 수행합니다. 이 문서에서는 "정상 연결" 방법을 사용하여 서비스 거부 공격을 생성합니다.
Port 19는 초기에는 Chargen 공격, 즉 Chargen_Denial_of_Service에 사용되었지만! 그들이 사용하는 방법은 두 개의 Chargen 서버 간에 UDP 연결을 생성하여 서버가 너무 많은 정보를 처리하고 다운되도록 하는 것입니다. 그런 다음 웹 서버를 종료하려면 두 가지 조건이 있어야 합니다. 1. Chargen 서비스가 있습니다. 2. 거기에 있습니다. HTTP Service
방식: 공격자가 소스 IP를 위조하여 N Chargen에 연결 요청(Connect)을 보냅니다. 연결을 받은 후 Chargen은 초당 72바이트 문자 스트림을 반환합니다. 실제 네트워크 상태).

5. Http 핑거프린팅 기술
Http 핑거프린팅의 원리는 기본적으로 동일합니다. 즉, 서로 다른 서버에서 HTTP 프로토콜 실행 시 약간의 차이를 기록하여 식별하는 것이 TCP/IP 스택 핑거프린팅보다 훨씬 더 복잡합니다. 사용자 정의 HTTP 서버 구성 파일은 플러그인이나 구성 요소를 추가하면 HTTP 응답 정보를 쉽게 변경할 수 있으므로 식별이 어려워지지만 TCP/IP 스택의 동작을 사용자 정의하려면 코어 레이어를 수정해야 하므로 쉽게 수행할 수 있습니다.
다른 배너 정보를 반환하도록 서버를 설정하는 것은 매우 간단합니다. Apache와 같은 오픈 소스 Http 서버의 경우 사용자는 소스 코드에서 배너 정보를 수정한 다음 적용되도록 Http 서비스를 다시 시작할 수 있습니다. 오픈 소스 코드가 없기 때문에 Microsoft의 IIS나 Netscape와 같은 HTTP 서버는 배너 정보를 저장하는 Dll 파일에서 수정될 수 있습니다. 관련 기사에서 이에 대해 논의했기 때문에 여기서는 물론 자세한 내용을 다루지 않겠습니다. 배너 정보를 흐리게 하는 또 다른 방법은 플러그인을 사용하는 것입니다.
일반적으로 사용되는 테스트 요청:
1: HEAD/Http/1.0은 기본 Http 요청을 보냅니다.
2: DELETE/Http/1.0은 삭제 요청과 같이 허용되지 않는 요청을 보냅니다.
3: GET/Http/3.0은 잘못된 버전의 HTTP 프로토콜 요청을 보냅니다
4: GET/JUNK/1.0은 잘못된 사양의 HTTP 프로토콜 요청을 보냅니다
Http 지문 식별 도구 Httprint는 통계 원리를 사용하여 퍼지 논리를 결합합니다. 학습 기술은 다음과 같은 작업을 수행할 수 있습니다. 다양한 HTTP 서버에서 생성된 서명을 수집하고 분석하는 데 사용할 수 있습니다.

6. 기타: 브라우저 사용 시 사용자의 성능을 향상시키기 위해 최신 브라우저에서는 웹 페이지를 탐색할 때 동시에 여러 연결이 설정되어 웹 페이지에서 여러 아이콘을 빠르게 얻을 수 있습니다. , 더욱 편리하게 전체 웹페이지 이전을 완료할 수 있습니다.
HTTP1.1은 이러한 지속적인 연결 방법과 차세대 HTTP 프로토콜을 제공합니다. HTTP-NG에는 세션 제어, 풍부한 콘텐츠 협상 및 기타 방법에 대한 지원이 추가되어
보다 효율적인 연결을 제공합니다.