一、背景

之前学习tcp协议的时候，tcp header的结构比较复杂，不容易理解，今天结合wireshark抓包加深下理解。

文章末尾参考资料非常重要，请注意： IETF Transmission Control Protocol Specification

二、TCP header

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Source Port          |       Destination Port        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Sequence Number                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Acknowledgment Number                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Data |       |C|E|U|A|P|R|S|F|                               |
  | Offset| Rsrvd |W|C|R|C|S|S|Y|I|            Window             |
  |       |       |R|E|G|K|H|T|N|N|                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           Checksum            |         Urgent Pointer        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Options                    |    Padding    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                             data                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           TCP Header Format
           Note that one tick mark represents one bit position.
1、Source Port: 16 bits
 The source port number.
2、Destination Port: 16 bits
 The destination port number.
3、Sequence Number: 32 bits
    The sequence number of the first data octet in this segment (except
 when SYN is present).  If SYN is present the sequence number is the
 initial sequence number (ISN) and the first data octet is ISN+1.
4、Acknowledgment Number: 32 bits
 If the ACK control bit is set this field contains the value of the
 next sequence number the sender of the segment is expecting to
 receive.  Once a connection is established this is always sent.
5、Data Offset: 4 bits
 The number of 32 bit words in the TCP Header.  This indicates where
 the data begins.  The TCP header (even one including options) is an
 integral number of 32 bits long.

其实就是标识TCP header的长度。

6、 Rsrvd - Reserved: 4 bits
 Reserved for future use.  Must be zero in generated segments and
 must be ignored in received segments, if corresponding future
 features are unimplemented by the sending or receiving host.
7、Control Bits: 8 bits (from left to right):
    CWR: Congestion Window Reduced (see [9])
    ECE: ECN-Echo (see [9])
    URG: Urgent Pointer field significant
    ACK: Acknowledgment field significant
    PSH: Push Function (see Paragraph 5)
    RST: Reset the connection
    SYN: Synchronize sequence numbers
    FIN: No more data from sender
8、Window: 16 bits
 The number of data octets beginning with the one indicated in the
 acknowledgment field which the sender of this segment is willing to
 accept.

 The window size MUST be treated as an unsigned number, or else
 large window sizes will appear like negative windows and TCP will
 now work (MUST-1).  It is RECOMMENDED that implementations will
 reserve 32-bit fields for the send and receive window sizes in the
 connection record and do all window computations with 32 bits (REC-
 1).
9、Checksum: 16 bits
    The checksum field is the 16 bit one's complement of the one's
 complement sum of all 16 bit words in the header and text.  If a
 segment contains an odd number of header and text octets to be
 checksummed, the last octet is padded on the right with zeros to
 form a 16 bit word for checksum purposes.  The pad is not
 transmitted as part of the segment.  While computing the checksum,
 the checksum field itself is replaced with zeros.

 The checksum also covers a pseudo header conceptually prefixed to
 the TCP header.  The pseudo header is 96 bits for IPv4 and 320 bits
 for IPv6.  For IPv4, this pseudo header contains the Source
 Address, the Destination Address, the Protocol, and TCP length.
 This gives the TCP protection against misrouted segments.  This
 information is carried in IPv4 and is transferred across the TCP/
 Network interface in the arguments or results of calls by the TCP
 on the IP.

               +--------+--------+--------+--------+
               |           Source Address          |
               +--------+--------+--------+--------+
               |         Destination Address       |
               +--------+--------+--------+--------+
               |  zero  |  PTCL  |    TCP Length   |
               +--------+--------+--------+--------+

 The TCP Length is the TCP header length plus the data length in
 octets (this is not an explicitly transmitted quantity, but is
 computed), and it does not count the 12 octets of the pseudo
 header.

 For IPv6, the pseudo header is contained in section 8.1 of RFC 2460
 [5], and contains the IPv6 Source Address and Destination Address,
 an Upper Layer Packet Length (a 32-bit value otherwise equivalent
 to TCP Length in the IPv4 pseudo header), three bytes of zero-
 padding, and a Next Header value (differing from the IPv6 header
 value in the case of extension headers present in between IPv6 and
 TCP).

 The TCP checksum is never optional.  The sender MUST generate it
 (MUST-2) and the receiver MUST check it (MUST-3).
10、Urgent Pointer: 16 bits
 This field communicates the current value of the urgent pointer as
 a positive offset from the sequence number in this segment.  The
 urgent pointer points to the sequence number of the octet following
 the urgent data.  This field is only be interpreted in segments
 with the URG control bit set.
11、Options: variable
 Options may occupy space at the end of the TCP header and are a
 multiple of 8 bits in length.  All options are included in the
 checksum.  An option may begin on any octet boundary.  There are
 two cases for the format of an option:

    Case 1: A single octet of option-kind.

    Case 2: An octet of option-kind, an octet of option-length, and
    the actual option-data octets.

 The option-length counts the two octets of option-kind and option-
 length as well as the option-data octets.

 Note that the list of options may be shorter than the data offset
 field might imply.  The content of the header beyond the End-of-
 Option option must be header padding (i.e., zero).

 The list of all currently defined options is managed by IANA [41],
 and each option is defined in other RFCs, as indicated there.  That
 set includes experimental options that can be extended to support
 multiple concurrent uses [34].

 A given TCP implementation can support any currently defined
 options, but the following options MUST be supported (MUST-4) (kind
 indicated in octal):

     Kind     Length    Meaning
     ----     ------    -------
      0         -       End of option list.
      1         -       No-Operation.
      2         4       Maximum Segment Size.

 A TCP MUST be able to receive a TCP option in any segment (MUST-5).
 A TCP MUST (MUST-6) ignore without error any TCP option it does not
 implement, assuming that the option has a length field (all TCP
 options except End of option list and No-Operation have length
 fields).  TCP MUST be prepared to handle an illegal option length
 (e.g., zero) without crashing; a suggested procedure is to reset
 the connection and log the reason (MUST-7).

Specific Option Definitions

    End of Option List

       +--------+
       |00000000|
       +--------+
        Kind=0

    This option code indicates the end of the option list.  This
    might not coincide with the end of the TCP header according to
    the Data Offset field.  This is used at the end of all options,
    not the end of each option, and need only be used if the end of
    the options would not otherwise coincide with the end of the TCP
    header.

    No-Operation

       +--------+
       |00000001|
       +--------+
        Kind=1

    This option code may be used between options, for example, to
    align the beginning of a subsequent option on a word boundary.
    There is no guarantee that senders will use this option, so
    receivers must be prepared to process options even if they do
    not begin on a word boundary.

    Maximum Segment Size (MSS)

       +--------+--------+---------+--------+
       |00000010|00000100|   max seg size   |
       +--------+--------+---------+--------+
        Kind=2   Length=4

    Maximum Segment Size Option Data: 16 bits

    If this option is present, then it communicates the maximum
    receive segment size at the TCP which sends this segment.  This
    value is limited by the IP reassembly limit.  This field may be
    sent in the initial connection request (i.e., in segments with
    the SYN control bit set) and must not be sent in other segments.
    If this option is not used, any segment size is allowed.  A more
    complete description of this option is in Section 3.7.1.
12、Padding: variable
    The TCP header padding is used to ensure that the TCP header ends
 and data begins on a 32 bit boundary.  The padding is composed of
 zeros.

三、TCB (Transmission Control Block)

Before we can discuss very much about the operation of the TCP we need to introduce some detailed terminology. The maintenance of a TCP connection requires the remembering of several variables. We conceive of these variables being stored in a connection record called a Transmission Control Block or TCB. Among the variables stored in the TCB are the local and remote socket numbers, the IP security level and compartment of the connection, pointers to the user’s send and receive buffers, pointers to the retransmit queue and to the current segment. In addition several variables relating to the send and receive sequence numbers are stored in the TCB.

   Send Sequence Variables

     SND.UNA - send unacknowledged
     SND.NXT - send next
     SND.WND - send window
     SND.UP  - send urgent pointer
     SND.WL1 - segment sequence number used for last window update
     SND.WL2 - segment acknowledgment number used for last window
               update
     ISS     - initial send sequence number

   Receive Sequence Variables

     RCV.NXT - receive next
     RCV.WND - receive window
     RCV.UP  - receive urgent pointer
     IRS     - initial receive sequence number

The following diagrams may help to relate some of these variables to the sequence space.

    Send Sequence Space

                  1         2          3          4
             ----------|----------|----------|----------
                    SND.UNA    SND.NXT    SND.UNA
                                         +SND.WND

       1 - old sequence numbers which have been acknowledged
       2 - sequence numbers of unacknowledged data
       3 - sequence numbers allowed for new data transmission
       4 - future sequence numbers which are not yet allowed

                         Send Sequence Space

                             Figure 2

The send window is the portion of the sequence space labeled 3 in Figure 2.

 Receive Sequence Space

                      1          2          3
                  ----------|----------|----------
                         RCV.NXT    RCV.NXT
                                   +RCV.WND

       1 - old sequence numbers which have been acknowledged
       2 - sequence numbers allowed for new reception
       3 - future sequence numbers which are not yet allowed

                        Receive Sequence Space

                             Figure 3

The receive window is the portion of the sequence space labeled 2 in Figure 3.

四、wireshark抓包

五、TCP Keep-Alives

Implementors MAY include “keep-alives” in their TCP implementations (MAY-5), although this practice is not universally accepted. If keep-alives are included, the application MUST be able to turn them on or off for each TCP connection (MUST-24), and they MUST default to off (MUST-25).

Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval (MUST-26). This interval MUST be configurable (MUST-27) and MUST default to no less than two hours (MUST-28).

It is extremely important to remember that ACK segments that contain no data are not reliably transmitted by TCP. Consequently, if a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection (MUST-29).

An implementation SHOULD send a keep-alive segment with no data (SHLD-12); however, it MAY be configurable to send a keep-alive segment containing one garbage octet (MAY-6), for compatibility with erroneous TCP implementations.

六、参考资料