TCP Segment Header Fields

Question 1

This is the 16 bit port number of the process that originated the TCP segment on the source device. This will normally be an ephemeral port number for a request sent by a client to a server, or a well-known/registered port number for a replay from a server to a client

Answer 1

Source Port (2 bytes)

Question 2

This is the 16 bit port number of the process that is the ultimate intended recipient of the message on the destination device. This will usually be a well-known/registered port number for a client request, or an ephemeral port number for a server reply.

Answer 2

Destination Port (2 bytes)

Question 3

For normal transmission, this is the sequence number of the first byte of data in this segment. In a connection request (SYN) message, this carries the ISN of the source TCP. The first byte of data will be given the next sequence number after the contents of this field

Answer 3

Sequence Number (4 bytes)

Question 4

When the ACK bit is set, this segment is serving as an acknowledgement (in addition to other possible duties), and this field contains the sequence number the source is next expecting the destination to send.

Answer 4

Acknowledgement Number (4 bytes)

Question 5

This specifies the number of 32 bit words of data in the TCP header. In other words, this value times four equals the number of bytes in the header, which must always be a multiple of four. It indicates by how many 32-bit words the start of the data is offset from the beginning of the TCP segment.

Answer 5

Data Offset (4 BITs)

Question 6

This field is reserved for future use, sent as zero

Answer 6

Reserved (6 BITs)

Question 7

TCP does not use a separate format for control messages. Instead, certain bits are set to indicate the communication of control information.

Answer 7

Control Bits (6 BITs)

Question 8

This indicates the number of octets of data the sender of this segment is willing to accept from the receiver at one time. This normally corresponds to the current size of the buffer allocated to accept data for this connection. In other words, this field is the current receive window size for the device sending this segment, which is also the send window for the recipient of the segment.

Answer 8

Window (2 bytes)

Question 9

This is for data integrity protection, computed over the entire TCP datagram, plus a special pseudo header of the fields. It is used to protect the entire TCP segment against errors in transmission as well as errors in delivery. Optional alternate methods to calculate this are also supported

Answer 9

Checksum (2 bytes)

Question 10

This is used in conjunction with the URG control bit for priority data transfer. This field contains the sequence number of the last byte of urgent data.

Answer 10

Urgent Pointer (2 bytes)

Question 11

TCP includes a generic mechanism for including one of more sets of optional data in a TCP segment. Each of the options can be either one byte in length of variable in length. The first byte is the Option-Kind subfield, and its value specifies the type of option, which in turn indicates whether the option is just a single byte of multiple bytes. Options that are many bytes consist of three fields.

Answer 11

Options (Variable)

Question 12

If the Options field is not a multiple of 32 bits in length, enough zeroes are added to pad the header so it is a multiple of 32 bits

Answer 12

Padding (Variable)

Question 13

This is the bytes of data being sent in the segment

Answer 13

Data (Variable)

Question 14

When set to 1, indicates that the priority data transfer feature has been invoked for this segment, and that the Urgent Pointer field is valid

Answer 14

URG (Urgent Bit)

Question 15

When set to 1, indicates that this segment is carrying an acknowledgement, and the value of the Acknowledgement Number field is valid and carrying the next sequence expected from the destination of this segment

Answer 15

ACK (Acknowledgement Bit)

Question 16

The sender of this segment is using the TCP push feature, requesting that the data in this segment be immediately pushed to the application on the receiving device.

Answer 16

PSH (Push Bit)

Question 17

The sender has encountered a problem and wants to reset the connection

Answer 17

RST (Reset Bit)

Question 18

This segment is a request to synchronize sequence numbers and establish a connection; the Sequence Number field contains the ISN of the sender of the segment

Answer 18

SYN (Synchronize Bit)

Question 19

The sender of the segment is requesting that the connection be closed.

Answer 19

FIN (Finish Bit)

Question 20

This specifies the option type

Answer 20

Option-Kind (1 byte)

Question 21

This is the length of the entire option in bytes, including the Option-Kind and Option-Length fields

Answer 21

Option-Length (1 byte)

Question 22

This field contains the option data itself. In at least one oddball case, this field is omitted (making Option-Length equal to 2)

Answer 22

Option-Data (Variable)

Question 23

This option is a single byte option that marks the end of all options included in this segment. This needs to be included only when the end of the options doesn’t coincide with the end of the TCP header.

Answer 23

Option Kind: 0
Option Length: -
Option Data: -

End of Option

Question 24

This option is a “spacer” that can be included between options to align a subsequent option on a 32-bit boundary if needed

Answer 24

Option Kind: 1
Option Length: -
Option Data: -

No Operation

Question 25

This option conveys the size of the largest segment the sender of the segment wishes to receive. Used only in connection request (SYN) messages.

Answer 25

Option Kind: 2
Option Length: 4 bytes
Option Data: Maximum Segment Size

Maximum Segment Size

Question 26

This options implements the optional window scale feature, which allows devices to specify much larger window sizes than would be possible with the normal Window field. The value in Option-Data specifies the power of 2 that the Window field should be multiplied by to get the true window size the sender of the option is using. E.e., if the value of Option-Data is 3, this means values in the Window field should be multiplied by 8, assuming both devices agree to use this feature. This allows very large windows to be advertised when needed on high-performance links.

Answer 26

Option Kind: 3
Option Length: 3 bytes
Option Data: Window Size Shift Bits

Window Scale

Question 27

This option specifies that this device supports the select acknowledgement feature (SACK). This was implemented as a 2-byte option with no Option-Data field, instead of a single-byte option like End of Option List or No-Operation. This was necessary because it was defined after the original TCP specification, so an explicit option length needed to be indicated for backward compatibility

Answer 27

Option Kind: 4
Option Length: 2 bytes
Option Data: -

Selective Acknowledgement Permitted

Question 28

This option allows devices supporting the optional selective acknowledgement feature to specify non-contiguous blocks of data that have been received so they are not retransmitted if intervening segments do not show up and need to be retransmitted.

Answer 28

Option Kind: 5
Option Length: Variable
Option Data: Blocks of Data Selectively Acknowledged

Selective Acknowledgement

Question 29

This option lets a device request that a checksum-generation algorithm other than the standard TCP algorithm be used fr this connection. Both devices must agree for it to be used.

Answer 29

Option Kind: 14
Option Length: 3 bytes
Option Data: Alternate Checksum Algorithm

Alternate Checksum Request

Question 30

This option includes a checksum, if the checksum value needed to implement an alternate checksum is too large to fit in the standard 16 bit Checksum field.

Answer 30

Option Kind: 15
Option Length: Variable
Option Data: Alternate Checksum

Alternate Checksum