三次握手-四次挥手
三次握手
第一次握手： 客户端给服务端发送一个
SYN（同步序列编号(Synchronize Sequence Numbers)）报文。第二次握手： 服务端收到客户端发送的
SYN报文后，进行应答，发送给客户端一个SYN+ACK(确认编号(Acknowledgement Number))报文。第三次握手： 客户端收到
SYN+ACK报文后之后，会回应服务端一个ACK报文。服务端收到客户端
ACK报文后，三次握手建立完成。
1.为什么是三次握手？不能是两次？
解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常，而两次却不可以
第一次握手： 客户端发送网络包，服务端收到。这样服务端可以得出结论：客户端的发送能力正常，服务端的数据接收的也正常。
第二次握手： 服务端发送包，客户端收到。这样客户端可以得出结论：服务端的接收能力正常，发送能力正常，客户端的发送能力正常，接收能力正常。但是此时服务端并不能确认客户端的接收能力是否正常。
第三次握手： 客户端发包，服务端收到，这样服务端就可以得出结论：客户端的接收/发送能力正常。服务端自己的发送/接收能力也正常。
说明
三次握手的过程中，客户端和服务端的状态也在发生变化：
开始状态：客户端是处于
closed的状态，服务端是处于listen状态；第一次握手： 客户端给服务端发送一个
SYN报文，并指明客户端的初始化序列号ISN(c)，此时客户端的状态处于SYN_Send状态；第二次握手： 服务端收到客户端的
SYN报文之后，会以自己的SYN报文作为应答，并指定了自己的初始化序列号ISN(s)，同时会把客户端的ISN+1作为ACK的值，表示服务端已经收到了客户端的SYN，此时服务端处于SYN_REVD的状态。第三次握手： 客户端收到服务端发送的
SYN报文之后，会应答服务端发送一个ACK报文，同样把服务端的ISN+1作为ACK的值，表示已经收到服务端的SYN报文，此时客户端处于establised的状态。当服务器收到客户端的
ACK报文后，也处于establised状态，双方建立链接完成。
1、确认双方的接受能力、发送能力是否正常。
2、指定自己的初始化序列号，为后面的可靠传送做准备。
3、如果是 https 协议的话，三次握手这个过程，还会进行数字证书的验证以及加密密钥的生成到。
2. TCP初始化序列号ISN
ISN（Initial Sequence Number） 是固定的吗?
三次握手的一个重要功能是客户端和服务端交换ISN，以便让对方知道接下来接收数据的时候如何按序列号组装数据。
TCP初始化序列号不能设置为一个固定值，因为这样容易被攻击者猜出后续序列号，从而遭到攻击。
RFC1948(RFC 1948 序列号攻击)中提出了一个较好的初始化序列号
ISN随机生成算法。
ISN = M + F(localhost, localport, remotehost,remoteport).
M：是一个计时器，这个计时器每隔4微秒加1。
F：是一个Hash算法，根据源IP、目的IP、源端口、目的端口生成一个随机数值。要保证hash算法不能被外部轻易推算得出，用MD5算法是一个比较好的选择。
3. 什么是半连接队列? 全连接队里？
- 客户端第一次发送SYN同步信号，客户端处于
SYN_SEND，服务器第一次收到客户端的SYN同步信号，然后服务端就会处于SYN_RCVD，此时双方还没有完全建立连接，服务器会把这种状态的请求连接放在一个队列里面，此队列为半连接队列。 - 已经完成三次握手，建立起来的连接就会放到全连接队里：全连接队列，如果队列满了，则可能会出现丢包的现象。
- 在tcp连接的三次握手中最后一次中丢包：服务器收到
SYN包后发出SYN+ACK数据包，服务器进入SYN_RECV状态。这个时候客户端发送ACK给服务器失败了，服务器没办法进入ESTABLISH状态，这个时候肯定不能传输数据的，不论客户端主动发送数据与否，服务器都会有定时器发送第二步SYN+ACK数据包，如果客户端再次发送ACK成功，建立连接。如果一直不成功，服务器会有超时（大概64s）设置，超时之后会给客户端发RTS报文，进入CLOSED状态，防止SYN洪泛攻击，这个时候客户端应该也会关闭连接。
4. SYN-ACK 重传次数 重传
- 服务器发送完SYN+ACK包之后，如果未收到客户端的确认(ACK)包， 服务器就会进行首次重传，等待一段时间如果仍未收到客户端确认包，则进行第二次重传，... 如果重传次数超过系统规定的最大重传次数（
Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5），系统会将该连接的信息从半连接队列中删除。 - 每次重传等待的时间不一定相同，一般会是指数增长：1s, 2s, 4s, 8s,...
- 但是Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包响应，方能感知到Server的错误。
5. 三次握手过程中可以修改数据吗？
第一次、第二次握手不可以携带数据。
第三次 握手是可以携带数据的。
说明
1. 假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 `SYN` 报文中放入大量的数据，
因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 `SYN` 报文的话，这会让服务器花费很多时间、
内存空间来接收这些报文。也就是说，第一次握手可以放数据的话，其中一个简单的原因就是会让服务器更加容易受到攻击了。
2. 第三次的话，此时客户端已经处于 `established` 状态，也就是说，对于客户端来说，已经建立起连接了，
并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据页没啥毛病。
四次挥手
- 对方一个
FIN报文，我方一个ACK报文，再我方一个FIN报文，对方一个ACK报文。
说明
初始阶段：双方都处于establised，假如是客户端先发起关闭请求：
第一次：客户端发送一个
FIN报文，报文中指定一个序列号，此时客户端处于FIN_WAIT1状态。第二次：服务端收到客户端的
FIN报文后，会发送应答ACK报文，且把客户端的序列号值 + 1作为应答ACK报文的序列值，表明已经收到客户端的报文，此时服务端处于CLOSE_WAIT2状态。客户端收到服务端的ACK应答报文后，处于FIN_WAIT2状态。第三次：服务端想断开连接，发送给客户端
FIN报文，且指定一个序列号，此时服务端处于LAST_ACK状态。第四次：当客户端收到服务端
FIN报文后，一样发送一个应答ACK报文作为应答，且把服务端发送的序列号值+1 作为自己ACK应答报文的序列号值，此时客户端处于TIME_WAIT。需要等一段时间确保服务端收到自己的ACK报文之后进入CLOSED状态。服务端收到客户端
ACK应答报文后，就处于关闭CLOSED状态LISTEN- 侦听来自远方TCP端口的连接请求；SYN-SENT-在发送连接请求后等待匹配的连接请求；SYN-RECEIVED- 在收到和发送一个连接请求后等待对连接请求的确认；ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；FIN-WAIT-1-FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。FIN-WAIT-2- 从远程TCP等待连接中断请求，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。；LAST-ACK- 等待原来发向远程TCP的连接中断请求的确认；TIME-WAIT-等待足够的时间以确保远程TCP接收到连接中断请求的确认，表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。CLOSED- 没有任何连接状态；这个表示初始状态。CLOSE-WAIT- 这种状态的含义其实是表示在等待关闭。当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢 ，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接CLOSING-这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
注意
注:`MSL`(最大分段生存期)指明TCP报文在Internet上最长生存时间,
每个具体的TCP实现都必须选择一个确定的`MSL`值.RFC 1122建议是2分钟,
但BSD传统实现采用了30秒.TIME_WAIT 状态最大保持时间是2 * MSL,也就是1-4分钟
