Editing Transmission Control Protocol (section)

==TCP segment structure==
Transmission Control Protocol accepts data from a data stream, divides it into chunks, and adds a TCP header creating a TCP segment. The TCP segment is then [[encapsulation (networking)|encapsulated]] into an Internet Protocol (IP) datagram, and exchanged with peers.{{sfn|RFC 9293|loc=2.2. Key TCP Concepts}}

The term ''TCP packet'' appears in both informal and formal usage, whereas in more precise terminology ''segment'' refers to the TCP [[protocol data unit]] (PDU), ''datagram''{{sfn|RFC 791|pp=5–6}} to the IP PDU, and ''frame'' to the [[data link layer]] PDU:

<blockquote>
Processes transmit data by calling on the TCP and passing buffers of data as arguments. The TCP packages the data from these buffers into segments and calls on the internet module [e.g. IP] to transmit each segment to the destination TCP.{{sfn|RFC 9293}}
</blockquote>

A TCP segment consists of a segment ''header'' and a ''data'' section. The segment header contains 10 mandatory fields, and an optional extension field (''Options'', pink background in table). The data section follows the header and is the payload data carried for the application.{{sfn|RFC 9293|loc=3.1. Header Format}} The length of the data section is not specified in the segment header; it can be calculated by subtracting the combined length of the segment header and IP header from the total IP datagram length specified in the IP header.{{citation needed|date=November 2023}}
{{APHD|start|title=TCP header format{{Sfn|RFC 9293|loc=3.1. Header Format}}}}
{{APHD|0|bits1=16|bits2=16|field1=Source Port|field2=Destination Port}}
{{APHD|4|bits1=32|field1=Sequence Number}}
{{APHD|8|bits1=32|field1=Acknowledgement Number (meaningful when ACK bit set)}}
{{APHD|12|bits1=4|bits2=4|bits11=16|field1=Data Offset|field2=Reserved|vfield3=CWR|vfield4=ECE|vfield5=URG|vfield6=ACK|vfield7=PSH|vfield8=RST|vfield9=SYN|vfield10=FIN|field11=Window}}
{{APHD|16|bits1=16|bits2=16|field1=[[Internet checksum|Checksum]]|field2=Urgent Pointer (meaningful when URG bit set){{Sfn|RFC 9293|loc=3.8.5 The Communication of Urgent Information}}}}
{{APHD|20|bits1=320|background1=linen|field1=(Options) If present, Data Offset will be greater than 5.{{break}}Padded with zeroes to a multiple of 32 bits, since Data Offset counts words of 4 octets.}}
{{APHD|60|bits1=0|background1=mistyrose|field1=Data}}
{{APHD|end}}
;{{APHD|def|name=Source Port|length=16 bits|text=Identifies the sending port.}}
;{{APHD|def|name=Destination Port|length=16 bits|text=Identifies the receiving port.}}
;{{APHD|def|name=Sequence Number|length=32 bits|text=Has a dual role:
:*If the SYN flag is set (1), then this is the initial sequence number. The sequence number of the actual first data byte and the acknowledged number in the corresponding ACK are then this sequence number plus 1.
:*If the SYN flag is unset (0), then this is the accumulated sequence number of the first data byte of this segment for the current session.}}
;{{APHD|def|name=Acknowledgment Number|length=32 bits|text=If the ACK flag is set then the value of this field is the next sequence number that the sender of the ACK is expecting. This acknowledges receipt of all prior bytes (if any).{{sfn|RFC 9293|loc=3.4. Sequence Numbers}} The first ACK sent by each end acknowledges the other end's initial sequence number itself, but no data.{{sfn|RFC 9293|loc=3.4.1. Initial Sequence Number Selection}}}}
;{{APHD|def|name={{Visible anchor|Data Offset}}|short=DOffset|length=4 bits|text=Specifies the size of the TCP header in 32-bit [[word (computer architecture)|words]]. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.{{citation needed|date=November 2023}}}}
;{{APHD|def|name=Reserved|short=Rsrvd|length=4 bits|text=For future use and should be set to zero; senders should not set these and receivers should ignore them if set, in the absence of further specification and implementation.
:From 2003 to 2017, the last bit (bit 103 of the header) was defined as the NS (Nonce Sum) flag by the experimental {{harvtxt|RFC 3540}}, ECN-nonce. ECN-nonce never gained widespread use and the RFC was moved to Historic status.<ref>{{Cite web |title=Change RFC 3540 "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" to Historic |url=https://datatracker.ietf.org/doc/status-change-ecn-signaling-with-nonces-to-historic/ |access-date=2023-04-18 |website=datatracker.ietf.org |language=en}}</ref>}}
;{{APHD|def|name=Flags|length=8 bits|text=Contains 8 1-bit flags (control bits) as follows:
:;{{APHD|def|name=CWR|length=1 bit|text=Congestion window reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism.{{sfn|RFC 3168|p=13-14}}{{efn|name=added3168|Added to header by {{harvtxt|RFC 3168}}}}}}
:;{{APHD|def|name=ECE|length=1 bit|text=ECN-Echo has a dual role, depending on the value of the SYN flag. It indicates:
::*If the SYN flag is set (1), the TCP peer is [[Explicit Congestion Notification|ECN]] capable.{{sfn|RFC 3168|p=15}}
::*If the SYN flag is unset (0), a packet with the Congestion Experienced flag set (ECN=11) in its IP header was received during normal transmission.{{efn|name=added3168}} This serves as an indication of network congestion (or impending congestion) to the TCP sender.{{sfn|RFC 3168|p=18-19}}}}
:;{{APHD|def|name=URG|length=1 bit|text=Indicates that the Urgent pointer field is significant.}}
:;{{APHD|def|name=ACK|length=1 bit|text=Indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.{{Sfn|RFC 793}}}}
:;{{APHD|def|name=PSH|length=1 bit|text=Push function. Asks to push the buffered data to the receiving application.}}
:;{{APHD|def|name=RST|length=1 bit|text=Reset the connection}}
:;{{APHD|def|name=SYN|length=1 bit|text=Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. Some other flags and fields change meaning based on this flag, and some are only valid when it is set, and others when it is clear.}}
:;{{APHD|def|name=FIN|length=1 bit|text=Last packet from sender}}}}
;{{APHD|def|name=Window|length=16 bits|text=The size of the ''receive window'', which specifies the number of window size units{{efn|Windows size units are, by default, bytes.}} that the sender of this segment is currently willing to receive.{{efn|Window size is relative to the segment identified by the sequence number in the acknowledgment field.}} (See {{slink||Flow control}} and {{slink||Window scaling}}.)}}
;{{APHD|def|name=[[Internet checksum|Checksum]]|length=16 bits|text=The 16-bit [[checksum]] field is used for error-checking of the TCP header, the payload and an IP pseudo-header. The pseudo-header consists of the [[IPv4#Source address|source IP address]], the [[IPv4#Destination address|destination IP address]], the [[List of IP protocol numbers|protocol number]] for the TCP protocol (6) and the length of the TCP headers and payload (in bytes).}}
;{{APHD|def|name=Urgent Pointer|length=16 bits|text=If the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte.}}
;{{APHD|def|name=Options|short=TCP Option|length=Variable 0–320 bits, in units of 32 bits|constraint=<code>size(Options) == (DOffset - 5) * 32</code>|text=The length of this field is determined by the ''[[#Data Offset|Data Offset]]'' field. 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.{{sfn|RFC 9293}}
:Options have up to three fields: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). The Option-Kind field indicates the type of option and is the only field that is not optional. Depending on Option-Kind value, the next two fields may be set. Option-Length indicates the total length of the option, and Option-Data contains data associated with the option, if applicable. For example, an Option-Kind byte of 1 indicates that this is a no operation option used only for padding, and does not have an Option-Length or Option-Data fields following it. An Option-Kind byte of 0 marks the end of options, and is also only one byte. An Option-Kind byte of 2 is used to indicate Maximum Segment Size option, and will be followed by an Option-Length byte specifying the length of the MSS field. Option-Length is the total length of the given options field, including Option-Kind and Option-Length fields. So while the MSS value is typically expressed in two bytes, Option-Length will be 4. As an example, an MSS option field with a value of {{Mono|0x05B4}} is coded as ({{Mono|0x02 0x04 0x05B4}}) in the TCP options section.}}
:Some options may only be sent when SYN is set; they are indicated below as <sup><code style="color:#000; background:#ccc;">[SYN]</code></sup>. Option-Kind and standard lengths given as (Option-Kind, Option-Length).
:{| class="wikitable"
|-
! Option-Kind
! Option-Length
! Option-Data
! Purpose
! Notes
|-
|0 
|{{n/a}}
|{{n/a}}
|End of options list
|
|-
|1
|{{n/a}}
|{{n/a}}
|No operation
|This may be used to align option fields on 32-bit boundaries for better performance.
|-
|2
|4
|SS
|Maximum segment size
|See {{slink||Maximum segment size}} for details. <sup><code style="color:#000; background:#ccc;">[SYN]</code></sup>
|-
|3
|3
|S
|Window scale
|See {{slink||Window scaling}} for details.{{sfn|RFC 7323}} <sup><code style="color:#000; background:#ccc;">[SYN]</code></sup>
|-
|4
|2
|{{n/a}}
|Selective Acknowledgement permitted
|See {{slink||Selective acknowledgments}} for details.{{sfn|RFC 2018|loc=2. Sack-Permitted Option}} <sup><code style="color:#000; background:#ccc;">[SYN]</code></sup>
|-
|5
|N (10, 18, 26, or 34)
|BBBB, EEEE, ...
|Selective ACKnowledgement (SACK){{sfn|RFC 2018|loc=3. Sack Option Format}}
|These first two bytes are followed by a list of 1–4 blocks being selectively acknowledged, specified as 32-bit begin/end pointers.
|-
|8
|10
|TTTT, EEEE
|Timestamp and echo of previous timestamp 
|See {{slink||TCP timestamps}} for details.{{sfn|RFC 7323}}
|-
|28
|4
|{{n/a}}
|User Timeout Option
|See {{IETF RFC|5482|link=no}}.
|-
|29
|N
|{{n/a}}
|TCP Authentication Option (TCP-AO)
|For message authentication, replacing [[MD5]] authentication (option 19) originally designed to protect [[Border_Gateway_Protocol|BGP]] sessions.<ref>{{cite web|url=https://datatracker.ietf.org/doc/html/rfc2385|title=Protection of BGP Sessions via the TCP MD5 Signature Option|date=August 1998 |publisher=IETF|access-date=2023-12-30 |last1=Heffernan |first1=Andy }}</ref> See {{IETF RFC|5925|link=no}}.
|-
|30
|N
|{{n/a}}
|Multipath TCP (MPTCP)
|See [[Multipath TCP]] for details.
|}
:The remaining Option-Kind values are historical, obsolete, experimental, not yet standardized, or unassigned. Option number assignments are maintained by the [[Internet Assigned Numbers Authority]] (IANA).<ref>{{cite web|url=https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1|title=Transmission Control Protocol (TCP) Parameters: TCP Option Kind Numbers|publisher=IANA|access-date=2017-10-19|archive-date=2017-10-02|archive-url=https://web.archive.org/web/20171002210157/http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1|url-status=live}}</ref>
;{{APHD|def|name={{Visible anchor|Data}}|length=Variable|text=The payload of the TCP packet}}