TCP
https://en.wikipedia.org/wiki/Transmission_Control_Protocol
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 clear (0), then this is the accumulated sequence number of the first data byte of this segment for the current session.
If the ACK flag is set then the value of this field is the next sequence number that the sender is expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each end acknowledges the other end's initial sequence number itself, but no data.
Specifies the size of the TCP header in 32-bit 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. （？） also the offset from the start of the TCP segment to the actual data.
For future use and should be set to zero.
https://tools.ietf.org/html/rfc3540 Robust Explicit Congestion Notification (ECN) Signaling with Nonces
The ECN-nonce enables the sender to verify the correct behavior of the ECN receiver and that there is no other interference that conceals marked (or dropped) packets in the signaling path.
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 (added to header by RFC 3168).
has a dual role:
If the SYN flag is set (1), that the TCP peer is ECN capable.
If the SYN flag is clear (0), that a packet with Congestion Experienced flag set (ECN=11) in IP header was received during normal transmission (added to header by RFC 3168). This serves as an indication of network congestion (or impending congestion) to the TCP sender.
indicates that the Urgent pointer field is significant
indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.
Asks to push the buffered data to the receiving application.
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 for when it is set, and others when it is clear.
the number of window size units(by default, bytes) (beyond the segment identified by the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive (see Flow control and Window Scaling).
error-checking of the header, the Payload and a Pseudo-Header.The Pseudo-Header consist of：the Source IP Address,the Destination IP Address,the protocol number for the TCP-Protocol (0x0006)the length of the TCP-Headers including Payload (in Bytes)
if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte.
if data offset > 5. Padded at the end with "0" bytes if necessary.
Zeros. ensure that the TCP header ends and data begins on a 32 bit boundary.
three phases. Connections must be properly established in a multi-step handshake process (connection establishment) before entering the data transfer phase. After data transmission is completed, the connection termination closes established virtual circuits and releases all allocated resources.
A TCP connection is managed by an operating system through socket.
http://www.medianet.kent.edu/techreports/TR2005-07-22-tcp-EFSM.pdf
(server)
(client) waiting for a matching connection request after having sent a connection request.
(server) represents waiting for a confirming connection request acknowledgment after having both received and sent a connection request.
(both server and client) normal state for the data transfer phase of the connection.
(both server and client) represents waiting for a connection termination request from the remote TCP, or an acknowledgment of the connection termination request previously sent.
(both server and client) represents waiting for a connection termination request from the remote TCP.
(both server and client) represents waiting for a connection termination request from the local user.
(both server and client) represents waiting for a connection termination request acknowledgment from the remote TCP.
(both server and client) represents waiting for an acknowledgment of the connection termination request previously sent to the remote TCP (which includes an acknowledgment of its connection termination request).
(either server or client) represents waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request. [According to RFC 793 a connection can stay in TIME-WAIT for a maximum of four minutes known as two MSL (maximum segment lifetime).]
(both server and client) represents no connection state at all.
three-way (or 3-step) handshake:
client sending a SYN to the server. client sets the segment's sequence number to a random value A.
server replies with a SYN-ACK. acknowledgment number: A+N sequence number：another random number：B
client sends an ACK back to the server. sequence number： A+N acknowledgement number：B+M
four-way handshake, with each side of the connection terminating independently.
A connection can be "half-open". The terminating side should continue reading the data until the other side terminates as well.
It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK.
Some host TCP stacks may implement a half-duplex close sequence, as Linux or HP-UX do. cause the remote stack to lose all the data received.
Some application protocols using the TCP open/close handshaking for the application protocol open/close handshaking may find the RST problem on active close.
receiver continually hints the sender on how much data can be received (controlled by the sliding window). When the receiving host's buffer fills, the next acknowledgment contains a 0 in the window size, to stop transfer and allow the data in the buffer to be processed.
TCP window size field controls the flow of data and its value is limited to between 2 and 65,535 bytes.
TCP window scale option, as defined in RFC 1323, is an option used to increase the maximum window size from 65,535 bytes to 1 gigabyte. used only during the TCP 3-way handshake. Both sides must send the option in their SYN segments to enable window scaling in either direction.
Some routers and packet firewalls rewrite the window scaling factor during a transmission. The result is non-stable traffic that may be very slow.
