tcp/ip協議中的SYN, ACK的數值變化

還需要論述一下seq、ack表示什么意思，應該以什么樣的角度去理解這兩個序列號。

• sequence number：表示的是我方（發送方）這邊，這個packet的數據部分的第一位應該在整個data stream中所在的位置。（注意這里使用的是“應該”。因為對於沒有數據的傳輸，如ACK，雖然它有一個seq，但是這次傳輸在整個data stream中是不占位置的。所以下一個實際有數據的傳輸，會依舊從上一次發送ACK的數據包的seq開始）
• acknowledge number：表示的是期望的對方（接收方）的下一次sequence number是多少。
• 注意，SYN/FIN的傳輸雖然沒有data，但是會讓下一次傳輸的packet seq增加一，但是，ACK的傳輸，不會讓下一次的傳輸packet加一。

上面這幾條原則第一次讀會有些抽象，可以先繼續往下讀分析過程，再回過頭來查看這個三個原則。

 

 

 

 

 

http響應數據比較大時， tcp包會分成很多塊， 分很多次傳輸。

四次揮手，斷開連接 

 

 https://superuser.com/questions/204861/why-a-single-tcp-packet-gets-split-to-multiple-pdu-units-here

I presume you are referring to visible frames in the range 56-78.
Lets tackle things in this order,

1. About: "TCP segment of a reassembled PDU"
   This implies that wireshark (ethereal?) reassembled TCP Segments together for your view.
   So, you can ignore this string, it means no harm.
   ^{I have elaborated what these frames are in point 4 below.}
2. About: Different frames with the same 'seq' number.
   Frames 58, 60,62,64,etc show the same sequence number.
   However, note that these are not a single packet "marked as separate packets" -- no splitting.
   These packets had only the 'ACK' flag set and you will see that the ACK number is incrementing.
   These are ACKs sent to the HTTP server from your machine as different TCP segments reached it.
3. The 'ACK' sequence starts at 1 in frame 52 and ends with 9646 in the FIN frame 78.
   During this time, all frames from your browser towards the HTTP server are repeating the last sequence number sent (which is 609) -- this is normal TCP protocol behavior.
   The browser is not sending any further data after its first HTTP request (frame 52).
   The HTTP server acknowledged this in frame 54.
4. I expect frame 54 is the (wireshark) re-assembled server response which was formed with the frames marked "TCP segment of a reassembled PDU".
   So, all those succeeding frames marked that way are from the HTTP server to the client
   (that detail is not visible in your picture since you scrubbed the Source and Destination columns).

If you re-check your original capture file, you should find frames 54 to 67 that have TCP Source port 80 (for HTTP) will add up to the 9646 byte response data from the HTTP server.

What you see here is a 9KB reply from the HTTP server reaching your browser as several MTU limited TCP segments, each of which was acknowledged by the TCP stack of your OS.

This is the high-level sequence of communication.

1. Your browser started connection to the HTTP server with a 3-way TCP handshake.
2. It sent a single HTTP Request to the server on this connection
3. The server replied to this with a 9 KB response which was spread over several TCP/IP packets as (TCP Segments)
4. The TCP/IP stack on your browser machine acknowledged each TCP packet as it was received from the server
5. Finally, it closed the connection starting with a FIN packet.
   I expect there were a couple of more FIN and ACK packets after frame 78 (or a single RSTpacket).

You can read up some more on Wireshark TCP Reassembly handling at the Wireshark Wiki.