문제의 원인을 주장하는 공급업체와 문제가 있는 것은 tcp 데이터의 잘못된 'ack' 값입니다. 저는 자바를 사용하고 있어서 이 레이어를 작성하지 않았습니다. 나는 snoop를 사용하여 유선 트래픽을 캡처하고 Wireshark를 사용하여 데이터를 표시하고 있습니다. 무슨 일이 일어나고 있는지 살펴보겠습니다. 다중 패킷(5) 메시지를 받은 후 다중 팩(3) 응답이 표시됩니다. 응답의 첫 번째 패킷에는 다른 두 패킷의 'ack' 값과 다른 'ack' 값이 있습니다. 공급업체는 이 데이터가 의심스럽다고 주장합니다. 아래에 샘플 데이터를 제공했습니다. 저는 TCP 전문가가 아니기 때문에 이것이 문제인지 아닌지는 모르겠습니다. 유효한 ack 값에 대해 뭔가를 찾으려고 노력했는데 값이 80018이어야 하는 것 같지만 그렇다고 78345가 잘못되었다는 의미는 아닙니다. 웹에서 이것을 찾았는데 적용되는 것 같지만 확실하지 않습니다. "모든 데이터 세그먼트의 ack 값은 보낼 다음 세그먼트에 앞서 데이터를 승인하지 않는 한 유효한 것으로 간주됩니다." 당신의 도움을 주셔서 감사합니다. 내 이해는 공급업체가 자체 TCP 계층을 작성했다는 것입니다.
소스 시퀀스 확인 시간
나 10734 75465 190 yyyymmdd 09:18:21.785757
공급업체 75465 10924 0 yyyymmdd 09:18:21.789319
공급업체 75465 10924 1440 yyyymmdd 09:18:34.196661
공급업체 76905 10924 1440 yyyymmdd 09:18:34.196762
공급업체 78345 10924 1440 yyyymmdd 09:18:34.196901
공급업체 79785 10924 233 yyyymmdd 09:18:34.196915
나 10924 78345 0 yyyymmdd 09:18:34.196968
나 10924 80018 0 yyyymmdd 09:18:34.197102
나 10924 80018 197 yyyymmdd 09:18:34.579479
답변1
http://en.wikipedia.org/wiki/Transmission_Control_Protocol라고
승인 번호(32비트) - ACK 플래그가 설정된 경우 이 필드의 값은 수신자가 기대하는 다음 시퀀스 번호입니다. 이는 모든 이전 바이트(있는 경우)의 수신을 승인합니다. 각 끝에서 보낸 첫 번째 ACK는 상대방의 초기 시퀀스 번호 자체를 확인하지만 데이터는 확인하지 않습니다.
이는 첫 번째 응답 패킷이 처음 3개 패킷의 수신을 승인하고 있음을 의미합니다.공급업체(시퀀스 76905 + len 1440 = 78345)
두 번째 응답 패킷은 4번째와 5번째 패킷의 수신을 확인합니다.공급업체(시퀀스 79785 + len 233 = 80018)
세 번째 응답 패킷은 더 이상 데이터가 수신되지 않았음을 나타냅니다.공급업체(동일한 ack) 197바이트의 페이로드를 포함합니다.
제가 보기에는 괜찮아 보입니다.
데이터가 전체 대화인 경우 첫 번째 패킷을 응답해야 하므로 초기 응답이 잘못될 수 있습니다.공급업체ack 75465(seq 75465 + 1 = 75466)입니다.
다음은 Wireshark로 캡처한 시퀀스입니다. 먼저 3방향 핸드셰이크를 확인한 다음 HTTP 가져오기 요청 전송과 HTTP 응답을 확인합니다.
소스 플래그 Seq Ack Len 클라이언트 SYN 0 - 0 서버 SYN,ACK 0 1 0 클라이언트 ACK 1 1 0 클라이언트 - 1 1 429 가져오기 ... 서버 ACK 1 430 0 서버 - 1 430 1456 HTML 응답 서버 - 1457 430 1456 클라이언트 ACK 430 2913 0 ...
시퀀스 및 확인 번호는 상대적입니다(각 끝의 무작위로 선택된 시작 번호에 대해).
일련의 요청에 단일 연결을 사용하는 것이 일반적인 최적화입니다. 버전 1.1에서 HTTP에 추가되었으며 다음과 같이 알려져 있습니다.지속적인 연결. TCP 연결을 설정하고 해제하는 데는 비용이 듭니다.
답변2
간단히 말해서 ACK 필드는 수신자가 발신자로부터 수신할 것으로 예상되는 다음 시퀀스 번호를 나타내는 데 사용됩니다. 즉, 마지막으로 수신된 세그먼트의 시퀀스 번호 + 해당 세그먼트의 길이입니다. (손실/재전송 처리와 관련된 몇 가지 다른 용도가 있지만 지금은 생략하겠습니다.)
TCP는 단일 응답으로 여러 세그먼트가 승인될 수 있도록 설계되었습니다. 이를 통해 대기 시간이 긴 링크를 보다 효율적으로 활용할 수 있습니다. 보다RFC1122그리고RFC2581, 특히 지연된 승인에 대한 섹션.
특정 질문에 따르면 TCP 스택에는 항상 일정 수준의 인터리빙이 있습니다. 즉, 마지막 패킷(seq 79785)이 수신 버퍼에 배치되었더라도 ACK가 연결의 다른 쪽 끝으로 다시 전송되어야 하기 전에 허용된 시간 내에 처리되지 않았을 수 있습니다. 귀하가 제공한 헤더는 제게는 완전히 정상적인 TCP 대화를 묘사하는 것 같습니다. 귀하의 공급 업체의 설명은 기껏해야 모호한 것 같습니다.