HTTP1.1 Wireshark 분석

http1.1

HTTP/1.0이 통신할 때마다 연결 설정 , 데이터 전송 및 연결 끊기의 세 단계를 거쳐야 합니다 . 페이지가 많은 외부 파일을 참조하는 경우 설정 및 연결 해제 프로세스로 인해 네트워크 오버헤드가 많이 증가합니다.

HTTP/1.0의 문제점을 해결하기 위해 1999년에 출시된 HTTP/1.1은 다음과 같은 특징을 가지고 있습니다.

긴 연결: TCP 연결 멀티플렉싱이 도입되었습니다. 즉, TCP는 기본적으로 닫혀 있지 않으며 여러 요청에 의해 멀티플렉싱될 수 있습니다.
동시 연결: 도메인 이름에 대한 요청으로 여러 개의 긴 연결을 할당할 수 있습니다(긴 연결에서 "헤드 오브 라인 차단" 문제 해결).
파이프라인 메커니즘(파이프라이닝)을 도입하면 TCP 연결이 동시에 여러 요청을 보낼 수 있습니다. (응답 순서는 요청 순서와 일치해야 하므로 일반적으로 사용되지 않습니다.)
PUT, DELETE, OPTIONS, PATCH 등과 같은 새로운 메소드가 추가되었습니다.
일부 캐시된 필드 추가(If-Modified-Since, If-None-Match)
중단점에서 업로드 재개를 지원하기 위해 요청 헤더에 범위 필드가 도입되었습니다.
응답 데이터를 청크(chunked)할 수 있도록 허용하여 대용량 파일 전송에 좋습니다.
인터넷 호스팅이 가능하려면 호스트 헤더가 필수입니다
. ———————————————————
저작권 설명: 이 글은 CC 4.0 BY에 이어 CSDN 블로거 "Front End Nanjiu"의 원본 글입니다. - SA 저작권 동의서, 재인쇄를 위해서는 원본 소스 링크와 이 성명을 첨부해 주세요.
원본 링크: https://blog.csdn.net/qq_41960279/article/details/123786121

Wireshark는 http 1.1 연결 유지의 2개의 http 요청을 분석합니다.

아래 그림과 같이:
여기에 이미지 설명을 삽입하세요

포트 8080이 여전히 좋지 않으면 브라우저 요청에서 다음 대화 상자를 볼 수 있습니다.
여기에 이미지 설명을 삽입하세요

클라이언트 SYN이 연결하려고 하지만 서버는 계속 RST를 반환합니다.

RST 플래그 사용:

RST는 Reset을 의미하며 연결을 비정상적으로 종료할 때 사용되는 것으로 TCP 설계에 있어서 없어서는 안 될 요소이다. 위에서 언급한 것처럼 연결을 끊기 위해 RST 패킷을 보낼 때, 위의 FIN 패킷과 달리 버퍼에 있는 패킷이 모두 나올 때까지 기다리지 않고 바로 버퍼 영역에 있는 패킷을 버리고, RST 패킷을 보냅니다. RST 패킷을 수신한 후 수신측에서는 확인을 위해 ACK 패킷을 보낼 필요가 없습니다.

TCP 핸들러는 비정상적인 순간으로 간주되는 순간에 RST 패킷을 보냅니다. 예를 들어, A가 B로 연결을 시작했지만 B가 해당 포트를 수신하지 않는 경우, 이때 B 운영 체제의 TCP 핸들러는 RST 패킷을 보냅니다.

또 다른 예로, AB가 정상적으로 연결을 맺은 상태에서 A는 B에게 FIN 패킷을 보내 연결 종료를 요청하고, B가 ACK를 보낸 후 네트워크 연결이 끊어지고 A는 여러 가지 이유로 연결을 포기합니다. 프로세스 재시작 등). Netcom이 연결된 후 B는 다시 데이터 패킷을 보내기 시작합니다. 이를 수신한 후 A는 심한 압박감을 표현합니다. 거친 연결이 어디서 오는지 모르기 때문에 RST 패킷을 보내 강제 연결을 합니다. B가 이를 수신한 후 피어 오류에 의한 연결 재설정이 나타납니다.

SpringBoot 프로젝트 8080 포트가 성공적으로 시작된 후 TCP 3방향 핸드셰이크가 성공한 것을 확인할 수 있습니다.

여기에 이미지 설명을 삽입하세요

그러다가 Tcp 창 업데이트를 봤습니다. TCPWindowUpdate는 TCP 통신의 상태입니다. 이런 일이 발생할 수 있는 이유는 여러 가지가 있지만 결국에는 수신자가 데이터를 읽는 것보다 보낸 사람이 데이터를 더 빠르게 전송한다는 사실 때문입니다. 버퍼의 수신 측 공간의 일부를 해제하여 보낸 데이터를 보관한 다음 WindowsUpdate를 보낸 사람에게 보내어 얼마나 빨리 데이터를 보내야 하는지 알려줌으로써 데이터 송수신이 정상적으로 돌아갈 수 있도록 해야 합니다. .

첨부 파일: Wireshark의 TCP 프롬프트
Tcp 이전 세그먼트 손실(tcp 이전 세그먼트 손실)
Tcpacked 세그먼트 손실(tcp 응답 손실)
Tcp 창 업데이트(tcp 창 업데이트)
Tcp dup ack(tcp 반복 응답)
Tcp 연결 유지(tcp 연결 유지)
Tcp 재전송( tcp 재전송)
Tcp ACK된 보이지 않는 세그먼트(tcp 보이지 않는 확인 응답)
tcp 포트 번호 재사용(tcp 포트 재사용)
tcp 재전송(tcp 재전송)
tcp 빠른 재전송(tcp 빠른 재전송)
TCP 이전 세그먼트 손실(발신자 데이터 세그먼트 손실)
tcp 스퓨리어스 재전송(tcp 의사 재전송)

그런 다음 http 요청이 전송됩니다.
여기에 이미지 설명을 삽입하세요

http 서버는 요청에 응답하고 반환합니다.
여기에 이미지 설명을 삽입하세요

다음 http 요청 응답(http1.1 Keep-Alive는 TCP 연결을 사용하므로 연결을 끊었다가 다시 연결할 필요가 없음)
여기에 이미지 설명을 삽입하세요

고객이 연결을 끊기 위해 4번 손을 흔들었습니다.
여기에 이미지 설명을 삽입하세요

Wireshark는 http1.1 연결 유지 만료 2개 요청을 분석합니다.

일반적인 연결 유지 매개변수

클라이언트 IE의 기본 KeepAliveTimeout은 1분입니다.
서버 IIS 기본 ConnectionTimeout 기간은 2분입니다.
서버 ASP.NetCore Kestrel 기본 KeepAliveTimeout=130s
서버 nginx 기본 keepalive_timeout=60s

아래 그림과 같이 http 요청 연결 유지가 만료되면 서버는 TCP 연결 해제를 시작하고 4번의 핸드셰이크를 완료합니다.

여기에 이미지 설명을 삽입하세요

다음 http 요청은 TCP 3방향 핸드셰이크를 다시 수행합니다.

여기에 이미지 설명을 삽입하세요

연결 유지 메시지

http 요청은 Kepp-Alive 시간
여기에 이미지 설명을 삽입하세요
만료 시간을 3초로 설정하고, 최대 요청 수는 최대 100개이며, 연결이 강제로 끊어집니다. 즉, 새 연결이 시간 초과 시간 내에 들어오고 최대값은 자동으로 다음과 같이 감소합니다. 1이 0이 될 때까지 강제로 연결을 끊습니다.

여기에 이미지 설명을 삽입하세요

클라이언트는 서버에 다음을 보냅니다. TCP 감지 패킷(TCP Keep-Alive)
서버는 클라이언트에게 ACK(TCP Keep-Alive ACK)를 반환합니다.

TCP KeepAlive감지 메시지는 데이터가 없는 메시지이며 ACK 플래그가 동시에 설정되며, 메시지의 시퀀스 번호는 지난 번 데이터 상호 작용이 발생했을 때 TCP 메시지의 시퀀스 번호에서 1을 뺀 값입니다. 예를 들어, Local End와 Peer End 사이의 마지막 데이터 교환의 마지막 순간에 Peer End가 Local End로 보낸 ACK 메시지의 시퀀스 번호는 N입니다(즉, 다음 번에 Local End가 전송하는 ACK 메시지). 데이터를 피어 측으로 보내는 경우 시퀀스 번호는 N이어야 함) 로컬 측에서 피어 측으로 데이터를 전송하는 경우 피어 측에서 보낸 연결 유지 감지 패킷의 시퀀스 번호는 N-1이어야 합니다.