TCP segment structure
Comes to the TCP protocol, we first think of the word is "connection-oriented" and "reliable." Yes, the design of the TCP protocol is to be able to establish between the client and the server is a reliable connection.
Speaking before the connection process, let's look at TCP segment structure through this structure, we can know what TCP can provide information:
Here are a few points to note:
- TCP protocol requires a four-tuple (source of the IP, source port, destination IP, destination port) to determine connection, it should be distinguished and UDP protocols. Say one more thing, IP address at IP segment, TCP segment is free IP address information.
- Basic TCP header length is 20 bytes, but due to the length of the "option" is uncertain, it is necessary to "Header Length" header field explicitly given length. It should be noted here that the unit header length field is 32bit, that is 4 bytes, so the minimum value of this field is 5.
- After the marked orange fields (confirmation number, the receive window size, ECE, ACK) for "reply" to each other, for example, the server receives packets from each other, do not send a single packet to respond, but wait a little , the profile is attached to the next data frame is sent to the client, which is incidentally technology.
- Window size is a 16-bit unsigned number, that window is limited to 65535 bytes, also limits the throughput performance of TCP, which is not very friendly for some high-speed and high-latency network (you can think about why) . Fortunately, TCP provides an additional window scaling (Window Scale) option allows the zoom value.
Below are eight flags of meaning, some older protocols, may not be the first two flags:
Although many flags, but if you put a specific scene of view, it is easy to understand their role in the.
TCP three-way handshake
For three-way handshake is between the client and server to establish a connection, this process is not complicated, but there are many details that need attention.
This figure is the handshake process, you can see a total of three passes messages between the client and the server, which is actually a three-way handshake between two machines confirm the status of each other, let's look a little bit.
The first handshake
首先是客户端发起连接，第一个数据包将 SYN 置位（也就是 SYN = 1），表明这个数据包是 SYN 报文段（也被称为段 1）。这一次发送的目的是告诉服务器，自己的初始序列号是 client_isn ，还有一个隐含的信息在图里没有表现出来，那就是告知服务端自己想连接的端口号。除了这些，客户端还会发送一些选项，不过这跟三次握手没多大关系，暂且按下不表。
段 1 里最需要注意的就是这个client_isn ，也就是初始序列号。「RFC0793^1」指出:
When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours.
翻译过来就是，初始序列号是一个 32 位的（虚拟）计数器，而且这个计数器每 4 微秒加 1，也就是说，ISN 的值每 4.55 小时循环一次。这个举措是为了防止序列号重叠。
但即使这样还是会有安全隐患——因为初始 ISN 仍然是可预测的，恶意程序可能会分析 ISN ，然后根据先前使用的 ISN 预测后续 TCP 连接的 ISN，然后进行攻击，一个著名的例子就是「The Mitnick attack^2」 。这里摘一段原文：
Mitnick sent SYN request to X-Terminal and received SYN/ACK response. Then he sent RESET response to keep the X-Terminal from being filled up. He repeated this for twenty times. He found there is a pattern between two successive TCP sequence numbers. It turned out that the numbers were not random at all. The latter number was greater than the previous one by 128000.
所以为了让初始序列号更难预测，现代系统常常使用半随机的方法选择初始序列号，详细的方法就不在这里展开了。
第二次握手
当服务器接收到客户端的连接请求后，就会向客户端发送 ACK 表示自己收到了连接请求，而且，服务器还得把自己的初始序列号告诉客户端，这其实是两个步骤，但是发送一个数据包就可以完成，用的就是前面说的捎带技术。图里的 ACK = client_isn + 1 是指确认号字段的值，要注意和 ACK 标志位区分开。
ACK 字段其实也有不少需要注意的点，不过这个跟滑动窗口一块讲比较直观，这里就先不提了。
这里重点强调一下，当一个 SYN 报文段到达的时候，服务器会检查处于 SYN_RCVD 状态的连接数目是否超过了 tcp_max_syn_backlog 这个参数，如果超过了，服务器就会拒绝连接。当然，这个也会被黑客所利用，「SYN Flood」就是个很好的例子。因为服务器在回复 SYN-ACK 后，会等待客户端的 ACK ，如果一定时间内没有收到，认为是丢包了，就重发 SYN-ACK，重复几次后才会断开这个连接，linux 可能要一分钟才会断开，所以攻击者如果制造一大批 SYN 请求而不回复，服务器的 SYN 队列很快就被耗尽，这一段时间里，正常的连接也会得不到响应。
服务器的这种状态称为静默（muted）。为了抵御 SYN Flood 攻击，服务器可以采用「SYN cookies」，这种思想是，当 SYN 到达时，并不直接为其分配内存，而是把这条连接的信息编码并保存在 SYN-ACK 报文段的序列号字段，如果客户端回复了，服务器再从 ACK 字段里解算出 SYN 报文的重要信息（有点黑魔法的感觉了），验证成功后才为该连接分配内存。这样，服务器不会响应攻击者的请求，正常连接则不会受到影响。
但 SYN cookies 本身有一些限制，并不适合作为默认选项，有兴趣可以自行 Google。
第三次握手
这是建立 TCP 连接的最后一步，经过前两次握手，客户端（服务器）已经知道对方的滑动窗口大小，初始序列号等信息了，这不就完了吗？为什么还要第三次握手？
这是因为服务器虽然把数据包发出去了，但他还不知道客户端是否收到了这个包，所以服务器需要等待客户端返回一个 ACK，表明客户端收到了数据，至此，连接完成。
连接建立后，进入传输数据的阶段，这里就涉及到很多很多技术，我会另写文章。
四次挥手
有了三次握手的基础，四次挥手就比较容易理解了：
四次挥手的过程其实很简单，就是服务器和客户端互相发送 FIN 和 ACK 报文段，告知对方要断开连接。
四次挥手里值得关注的一点就是 TIME_WAIT 状态，也就是说主动关闭连接的一方，即使收到了对方的 FIN 报文，也还要等待 2MSL 的时间才会彻底关闭这条连接。（这里面的 MSL 指的是最大段生成期，指的是报文段在网络中被允许存在的最长时间。）可为什么不直接关闭连接呢？
一个原因是，第四次挥手的 ACK 报文段不一定到达了服务器，为了不让服务器一直处于 LAST_ACK 状态（服务器会重发 FIN，直到收到 ACK），客户端还得等一会儿，看看是否需要重发。假如真的丢包了，服务器发送 FIN ，这个 FIN 报文到达客户端时不会超过 2MSL（一来一回最多 2MSL），这时候客户端这边的 TCP 还没关掉，还能重发 ACK。
另一个原因是，经过 2MSL 之后，网络中与该连接相关的包都已经消失了，不会干扰新连接。我们来看一个例子：假如客户端向服务器建立了新的连接，旧连接中某些延迟的数据坚持到了新连接建立完毕，而且序列号刚好还在滑动窗口内，服务器就误把它当成新连接的数据包接收，如下图所示：
2MSL 机制就避免了这种情况。
关于 TIME_WAIT 还有很多有意思的地方，我觉得可以单独再写一篇文章了，这里就不再多说。
感觉写的有点乱了，因为 TCP 的知识确实是有点多，希望各位读者不要介意。