The last article briefly introduced the basis of TCP protocol, also did not involve the specific packet capture, do not know I said the three handshake is not right, today to start from the analysis of packet capture.
3.1 Analyze the three-way handshake again
Capture package tool should be able to use it, baidu you will know, here will not describe, I this capture package is, with SCP command to copy the local virtual machine file to the server, so it caught some packages.
Grab the package is not a face meng force, which is so different from the “TCP/IP Details” I saw? I do not know the reason, actually caught out of the bag there are so many do not understand, then the next analysis of the meaning of the bag
3.1.1 TCP DUP ACK and TCP out-of-order Packets
TCP dUP ACK, TCP out-of-order ack, TCP out-of-order ACK, TCP out-of-order ACK, TCP out-of-order ACK, TCP out-of-order ACK
3.1.1.1 TCP Out_of_Order Causes:
Typically, network congestion causes sequential packets to arrive at different times, too long a delay, or packets to be lost and data units to be recombined because they may have taken a different route to your computer.
3.1.1.2 TCP Retransmission Causes:
It is clear that the above timeout caused the data to be retransmitted.
3.1.1.3 TCP dup ack XXX#X
The sequence number to which the packet was lost and the sequence number to which the packet was lost.
3.1.1.4 TCP Previous segment not Captured
It means that the packet is not captured and the packet is lost.
Here again worship god, also write this god in order to solve doubts, his blog is also carried out below the analysis of the package, but I here also caught the package, not its, their own analysis of a wave.
3.1.2 Analyze the three-way handshake again
The syn is out of order. I don’t know why it’s out of order. In general, the client sends a SYN to the server. The server sends an ACK back to the client, and when the client receives the ACK, it sends an ACK back to the server, but it looks like it was lost, and then sends another ACK back, and this time the server receives the ACK.
3.2 Option bytes
TCP series 08 — Connection management — 7, TCP common options (option), interested can go to see.
According to RFC793, a TCP option requires only single-byte alignment, but is typically implemented either as a two-byte alignment or as a four-byte alignment via NOP options, such as the 3bytes WSOPT option. When Linux adds this TCP option, This option is preceded by a 1byte NOP option to make 4bytes.
TCP options have two formats. One is single-byte TCP options such as EOL and NOP. The other option is to contain 1byte of kind, 1byte of length, plus the option data. All TCP options except EOL and NOP are in the latter format. For compatibility, the protocol requires that the latter format be used when other TCP options are extended.
The RFC1122 protocol specifies that the TCP receiver must be able to process any TCP packet option. If the TCP option is not recognized, it is ignored. Some options, such as EOL, NOP and MSS, must be supported by the protocol, and the protocol requires that all new TCP options in the future be in the length field, so that the TCP implementation can skip this option if it cannot recognize this option.
3.2.1 The EOL format is as follows
+--------+
|00000000|
+--------+
Kind=0
Copy the codeThis option is used to indicate the end of the TCP option list. This option is used after all TCP options. Not all TCP options need this option to indicate the end of the option. Use the EOL option only when the list of TCP options does not overlap with the Header Length specified in the TCP Header field, and this option does not have to be placed at the end of the TCP Header (including extension headers). For example, if Header Length specifies a TCP Header Length of 40bytes and 29-38bytes is the TSOPT option, you can add an EOL option at 39th byte to indicate the end of the options list. You can see that EOL does not have the 40th byte at the end of the TCP Header. The last byte RFC793 must be filled with 0 according to the protocol. Note that the 0 after the EOL is no longer part of the TCP option.
3.2.2 The NOP option format is as follows
+--------+
|00000001|
+--------+
Kind=1
Copy the codeThis option can be used between options or at the end. For example, to make the 3bytes WSOPT option end at a four-byte aligned boundary, you can add a NOP option before the WSOPT option so that the entire option is 4bytes long and easier to align. However, according to the RFC793 protocol, the sender is not guaranteed to populate NOP options for other options to align, so the receiver should also be prepared to receive WSOPT options that are not four-byte aligned. That is to say, the same TCP options can have different order of arrangement. Even the same order may have different arrangement due to NOP and EOL, etc.
Finally, from a Linux implementation perspective, Linux itself does not add the EOL option when sending TCP packets, Instead, add one or more NOP options to align the entire TCP Header Length with four bytes. (remember that the Header Length field in a TCP Header is a 32-bit word, so a TCP Header must be a multiple of 4bytes.) Linux, however, supports parsing the EOL option when receiving packets. In addition, the protocol does not limit the order of TCP options, but Linux implementations do order TCP options in a certain order. The reason is that although the protocol does not limit the order of options, some devices on the Internet are sensitive to this order, and certain options order may cause problems.
3.2.3 MSS
Maximum segment Size (MSS) format is as follows
+--------+--------+---------+--------+
|00000010|00000100| max seg size |
+--------+--------+---------+--------+
Kind=2 Length=4
Copy the codeThe Maximum segment size(MSS) indicates the Maximum length of the packet that the TCP expects to receive from the peer end. Note that the MSS value indicates only the LENGTH of the TCP data and does not include the length of the associated TCP header and IP header. When a connection is being established, each endpoint usually advertises its MSS through MSS option in the corresponding SYN packet. RFC1122 uses the default 536bytes as the MSS if no MSS option is provided. (Note that the original RFC793 protocol stated that packets of any size could be sent when no MSS option was provided, which has been corrected by RFC1122.) Note that network adapters generally support TSO and GSO functions. If these functions are enabled, the TCP layer in the protocol stack may send packets in integer multiples of MSS, and then segment TCP by network adapter hardware, which reduces the CPU processing pressure. In order to facilitate the discussion of window management and other features, we still according to the TCP layer maximum packet does not exceed MSS to discuss.
In IPV6 Jumbogram (RFC2675), if the MSS value received by the receiver is 65535, the real MSS value must be determined by the PMTU value. The MSS = PMTU – 60. (Jumbogram is an IPV6 protocol feature for sending oversized IP packets. PMTU is the minimum MTU of all devices on the link between the receiving end and the sending end.)
RFC6691 clarifies the MSS options and corrects several previous RFC misstatements. RFC6691 explicitly states that the MSS value passed in the MSS option is MTU minus the VALUE of the IP base header (ipv4:20bytes, IPV6:40bytes) and TCP base header (20bytes), regardless of the extension header. Before sending data, the sender deducts the length of the extension header based on the MSS value to get the actual length of the transmitted data.
3.2.4 WSOPT
The WSOPT format is as follows
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+
Copy the codeRFC1323 provides two high-performance extensions for fusing pipelines, one WSOPT option and the other TSOPT option. Long – fat pipeline refers to the network with large bandwidth delay product.
The Window Size field is a 16-bit field with a maximum Size of 2^16-1. The WSOPT option is used when sending TCP needs to advertise a larger receive Window. When the WSOPT option is used, the actual Size of the receiving Window is Window Size<<shift. CNT, where shift. CNT can be a maximum of 14 according to the protocol. If shift. CNT received by the receiving end is larger than 14, the Window Size is 14.
The WSOPT option can only be sent in SYN packets, so when the TCP connection is established, the Window scale is fixed. Typically, TCP implementations have a maximum receive cache that determines the maximum receive window and window scale. The WSOPT option expands the existing 16-bit Window Size to nearly 30 bits (about 1GB), effectively increasing the receive cache that TCP allows, thus improving the performance of a long fat network.
To enable Window Scale, the sender sends the WSOPT option in the SYN packet, and the receiver sends WSOPT in the SYN-ACK packet. Notice During window scale negotiation, the protocol does not apply WSopt to window size in SYN and SYN-ACK packet headers. Shift. CNT in WSOPT can be 0, indicating that the window scale factor is 1(2^0=1), that is, the actual Size of the receiving window is window Size. If the sender sends the WSOPT option but does not receive the WSOPT option from the peer, it needs to set its window Scale factor to 1.
The sender and the receiver each have a receive window and a send window, so there are four Windows in total, maintaining four Scale factors in total. Assume that the scale factor of the receiving window of the sender is R and the scale factor of the sending window is S, then the corresponding receiving window scale factor of the receiver is R and the scale factor of the sending window is S. After the negotiation of scale factor at both ends, the Window Size field in the subsequent received packet will automatically carry out scale factor, and this field in the sent packet will be the result of the actual receiving Window moving right scale factor.
3.2.5 ACK – Permitted and SACK
The SACK – Permitted formats
Kind: 4
+---------+---------+
| Kind=4 | Length=2|
+---------+---------+
Copy the codeThe SACK format
Kind: 5 Length: Variable +--------+--------+ | Kind=5 | Length | +--------+--------+--------+--------+ | Left Edge of 1st Block | +--------+--------+--------+--------+ | Right Edge of 1st Block | +--------+--------+--------+--------+ | | / . . . / | | +--------+--------+--------+--------+ | Left Edge of nth Block | +--------+--------+--------+--------+ | Right Edge of nth Block | +--------+--------+--------+--------+Copy the codeWe have introduced TCP sliding window and ACK mechanism before. Let’s take a simple example. Suppose that the receiving end receives bytes with sequence number 2100 in sequence. The receiving end does not receive the TCP packet with the series NUMBER 2101, but the TCP packet with the series number 2201 and the length of the PACKET is 100 bytes. In other words, the receiver is missing between 2101 and 2200 bytes of data, which we call a hole in the slide window. The red part in the following figure indicates the data received by the receiving end.
In this case, when the receiver sends an ACK packet to the sender, the ACK number field in the TCP header can only be 2101. Remember that the ACK number indicates the sequence number of the next byte that the receiver expects to receive. It is the maximum sequence number of consecutive received packets plus 1. Notice that it is a continuous packet, because there are holes between 2100 and 2201, so the ACK number can only be 2101. After receiving the ACK number 2101, the sender cannot know that the receiver has actually received 2201-2300byte. Therefore, it is possible to retransmit 2201-2300byte data as well as 2101-2200byte data. Then, with SACK, the receiver can use SACK to tell the sender that it has received 2201-2300bytes of data, which is a SACK block. Combined with ack number, the sender can only retransmit 2101-2200bytes of data. No need to retransmit 2201-2300byte data.
An endpoint that resolves sack-ack packets with the sac-ACK option indicates that the peer end supports the SACK extension. In this case, the local end can send the received discontinuous packet information to the peer end for efficient retransmission. In general, the sac-permitted option is sent in SYN packets. Once a sac-permitted option is received, it can be transmitted in any packet. In Linux, the /proc/sys/net/ipv4/tcp_sack command controls whether to enable the SACK function. If the value is set to 1, the SACK function is enabled. If the value is set to 0, the SACK function is disabled. Because the SACK option has a lot to do with TCP retransmission, congestion control, and so on, we’ll talk more about this later.
3.2.6 TSOPT
The TSOPT format is as follows
Kind: 8
Length: 10 bytes
+-------+-------+---------------------+---------------------+
|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
+-------+-------+---------------------+---------------------+
1 1 4 4
Copy the codeThe TSOPT option is also called the TIMESTAMP option and is sometimes written as TSOPT. As mentioned above in WSOPT, TSOPT is also a TCP extension proposed by RFC1323 to improve the fusing pipeline. When using this option, the sender places a timestamp at TSval, which the receiver returns via TSecr. Because the receiver does not process the TSval but simply returns it directly from TSecr, there is no need for clock synchronization. This timestamp is generally a monotonically increasing value, and RFC1323 recommends that this timestamp increase by at least 1 per second. In the initial SYN packet, because the sender has no timestamp information, TSecr is filled with 0, and TSval with its own timestamp information.
In RFC1323, TSOPT has two main uses. One is round-trip time measurement (RTTM), which measures the round-trip delay based on this option in ACK packets. Another use is PAWS(Protect against Wrapped Sequence Numbers), which prevents overlapping of series numbers of the same link. In addition, there are some other uses, such as SYN-cookie, Eifel Detection Algorithm and so on. We will save RTTM for the TCP retransmission section, and here we briefly introduce PAWS.
PAWS assumes that the TSval in each RECEIVED TCP packet increases monotonously over time. The basic idea is that if the TSval in a received TCP packet is smaller than the TSval of the packet just received on this connection, the packet can be considered as an old duplicate packet and discarded. In fact, if the series number of the received TCP packet falls outside the receiving window, it can be discarded. However, on some high-speed and unstable networks, an invalid series number of the retransmitted packet falls into the receiving window after the series number is flipped. In this case, the serial number alone is not enough to verify the validity of the TCP packet. Combined with TSOPT, the timestamp option can be used to further filter out old duplicate packets.
Like PAWS, the timestamp actually acts as an extension of the serial number, monotonously incrementing on the same connection. RFC6191 further takes advantage of this feature, allowing connections to be established even in time-wait state when the timestamp increases monotonically between different instances of the same connection.
RFC7323 specifies that the TSecr field is valid only when the ACK bit in the TCP header is valid. If the ACK bit is not set, the sender should set TSecr to 0. The sender must echo a recently received TSval in the TSecr when the ACK flag bit is sent. When the ACK flag bit is not set, the receiver must ignore the TSecr field.
TCP can send the TSopt option in the initial SYN packet, but the receiving end can send the TSopt option in the SYN-ACK packet only when the TSopt option is resolved in the initial SYN packet. Once the TSopt option is negotiated through SYN and SYN-ACK packets at both ends of TCP communication, the TSopt option must be sent in subsequent non-RST packets. When receiving a non-RST message without the TSopt option, TCP should silently discard the message. TCP cannot abort a TCP connection due to the lack of the expected TSopt option. Note That the protocol does not silently discard data packets. For example, after TSopt is negotiated, Linux receives data without the TSopt option. The following articles provide an example of wireshark.
When the TSopt option is not negotiated during the three-way handshake and is received during subsequent data transmission, TCP must ignore the TSopt option and process the TCP packet normally. If one SYN packet contains the TSopt option and another SYN packet does not, both ends can send the TSopt option in subsequent SYN-ACK packets.
The TSopt option also has two important functions: RACK retransmission and the Eifel detection algorithm, which we’ll focus on as examples in a later article. In Linux, you can enable TSopt in /proc/sys/net/ipv4/tcp_timestamps. If this parameter is set to 0, TCP connections do not use TSopt.
3.2.7 FOC
The format of the FOC option is as follows
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: value = 34
Length 1 byte: range 6 to 18 (bytes); limited by
remaining space in the options field.
The number MUST be even.
Cookie 0, or 4 to 16 bytes (Length - 2)
Copy the codeThe Fast Open option is used to request or send a FOC(Fast Open Cookie). When the Cookie field is empty, the client uses this option to request a FOC from the server. When the cookie field is not empty, the server can use this option to pass cookies to the client, or the client can use this option to perform TFO.
The minimum cookie size is 4 bytes. Although cookies are 32-bit aligned, this option is not mandatory and should be ignored when packets do not contain the SYN flag, the Length value is invalid, or the TFO function is not enabled.
Option byte finally copy finished, really a bit much, before also feel not always, so understand finished, then come back to see capture package, you know the meaning of each field.
TCP: indicates a TCP protocol
Length:74 Indicates that the Length of the packet is 74 bytes
56739->443: indicates that port 443 is sent from port 56739 of the source address to port 443 of the destination address
[SYN] indicates that this is a TCP synchronization request and is the first step in the TCP handshake
Seq=0: indicates the TCP sequence number, which is 0.
First in the TCP SYN packet contains the sequence is random, and the first SYN + ACK packet sequence is random, wireshark to you are using relative value for observation, initialize the two random value is 0, Win=29200: The receiving window on the side of the sending message segment. TCP field
Len=0: indicates the length of the Datas segment
MSS=1460: Indicates the maximum length of the data field in each TCP packet segment. It doesn’t contain the header length. Is an option field in the TCP header.
WS=128: window expansion factor; Can only be determined during connection establishment; Its value cannot change during connection; The new window value = the window value defined in the header multiplied by 2 to the power of (window expansion factor); There are not enough window values. Fields in options. ?? The book says that the window expansion option takes up three bytes, one byte represents the shift value S, S is at most 14, and the new window value is equal to the increase of the number of window bits in the TCP header from 16 to (16+S). But why is WS equal to 128?
A: 128 here means that the window is enlarged 128 times, S=7, 2 ^ 7 = 128. Compliance with S<=14. Open the software below the TCP section of the detailed instructions, are introduced. (After calculation, the original data is 7)
SACK_PERM=1: allows select confirmation. Field in the TCP option