正文

tcp/ip协议中的SYN, ACK的数值变化

IP云
IP云V管理员/3 阅读
11/28
提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

还需要论述一下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 RST packet).

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

相关阅读

目录[+]