TCP的3次握手与4次挥手

前言

TCP协议是运输层协议的一种，它提供可靠的数据传输服务。TCP连接时全双工通信，这意味通信的双方都可以同时发送和接收数据，这有助于我们理解下面的握手与挥手过程！

TCP连接作为HTTP连接的前置，是由TCP连接来保证上面应用层的HTTP协议的工作的。

我们不仅要弄清楚流程，还要弄清楚客户端和服务器的状态变化情况！

一、TCP连接建立的3次握手

流程分析：

0.服务器server运行之后，就会打开端口开启socket通信，这时候服务器会监听外部的TCP连接建立的请求。所以其状态由closed变成listening。

服务器一直等待着外部的连接请求。

1.客户端client在没有建立连接的情况下，初始为closed状态。当它主动发出TCP连接请求的时候，它发送的报文段首部字节中就包含了TCP连接的信息（图中名词都是首部字节中的字段K-V数据）。client发送SYN=1, seq=X：SYN是指SYNchronized，即同步字段，当SYN=1时，则表示这是一个连接请求报文段；seq是指sequence，即序列号，它用来告诉对方我的报文段的序列号。当客户端发送出请求报文段后，自身的状态就变为了SYN_SENT，这很好理解，表示已发送请求。

客户端开始发送TCP连接的请求，首先它对服务器发送一个请求报文。客户端需要知道服务器能不能发送消息和接收消息？

2.服务器server接收到请求报文段后，也会发送ACK=1, ACKnum=1, SYN=1, seq=Y的报文段。SYN=1表明了这是一个请求连接报文段（很公平对不对？客户端先请求建立连接，服务器后也请求建立连接！）ACK=1，即acknowledge，这是确认号。当一方主动发送SYN=1的连接请求时，若己方同意建立连接，则必须回复SYN=1和ACK=1的报文段。ACKnum=X+1表示我想接收的下一个报文段的开始序列号应该是X+1，这就回复了对方（你下次发送的数据的序列号不要错，接着上一次的就好了）。服务器发送后，状态变成SYN_REVN，即请求连接已回复。

服务器接收到客户端的请求后，知道了客户端能发送消息，但是不知道能不能接收我的消息；所以服务器也发送一个请求报文回去，同时告诉客户端我收到了你的请求。

3.客户端client接收到服务器的请求报文段后，回复ACK=1, ACKnum=Y+1的报文段。ACK=1表示同意建立连接。客户端发送后，状态变成ESTABLISHED。

客户端接收到服务器的回复报文后，知道服务器既能接收消息，也能发送消息。那么客户端可以放心大胆地发送数据了，客户端发送确认报文给服务器。

5.服务器server接收到回复报文后，知道客户端不仅能发送消息，也能接收到我的消息。那么我也可以放心大胆地发送数据了。服务器接收后，状态变成ESTABLISHED。

剖析流程：

其实TCP连接建立的目的很简单：客户端和服务器都要确认对方的状态，既能发送数据也能接收数据！我们明白这个目的后就能明白3次握手的具体事宜了。

为什么要3次握手而不是2次握手？

第一点： 是为了保证上面我们所讲的3次握手的意义，确认双方的发送和接收状态。

第二点： 实际情况的例证说明。这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判！

比如：客户端发送了一个连接请求报文段A到服务端，但是在某些网络节点上长时间滞留了，而后客户端又超时重发了一个连接请求报文段B该服务端，然后正常建立连接，数据传输完毕，并释放了连接。但是请求报文段A延迟了一段时间后，又到了服务端，这本是一个早已失效的报文段，但是服务端收到后会误以为客户端又发出了一次连接请求，于是向客户端发出确认报文段，并同意建立连接。

那么问题来了，假如这里没有三次握手，这时服务端只要发送了确认，新的连接就建立了，但由于客户端没有发出建立连接的请求，因此不会理会服务端的确认，也不会向服务端发送数据；而服务端却认为新的连接已经建立了，并在一直等待客户端发送数据，这样服务端就会一直等待下去，直到超出保活计数器的设定值，而将客户端判定为出了问题，才会关闭这个连接。这样就浪费了很多服务器的资源！而如果采用三次握手，客户端就不会向服务端发出确认，服务端由于收不到确认，就知道客户端没有要求建立连接，从而不建立该连接。

引申，TCP的3次握手缺陷而引起的SYN Flood攻击！也就是最经典的分布式拒绝服务攻击！

SYN Flood 攻击

SYN- Flood攻击是当前网络上最为常见的Dos/DDoS攻击，也是最为经典的拒绝服务攻击，它就是利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现，但至今仍然显示出强大的生力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。

它的数据包特征通常是，源发送了大量的SYN包，并且缺少三次握手的最后一步握手ACK回复。
原理：攻击者首先伪造地址对服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。服务器没有收到回应，这样的话，服务器不知道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。

Dos/DDos攻击：

1、Dos是利用自己的计算机攻击目标，也是一对一的关系，而DDOS是DoS攻击基础之上产生的一种新的攻击方式,利用控制成百上千台肉鸡，组成一个DDOS攻击群，同一时刻对目标发起攻击。Dos是拒绝服务攻击，而DDOS是分布式拒绝服务攻击；DOS与DDOS都是攻击目标服务器、网络服务的一种方式。

2、从理论上来说，无论目标服务器、网络服务的资源多大，也是带宽、内存、CPU多大，都无法避免Dos与DDOS攻击，因此任何资源再大也有一个极限值，比如说，一台服务器每秒可以处理1000个数据包，而通过DOS攻击给这台服务器发送1001个数据包，这时服务器无法正常运行，需要给服务器扩容。

3、从技术上来说，DOS和DDOS都是攻击目标服务器的带宽和连通性，使得目标服务器的带宽资源耗尽，无法正常运行。

SYN Flood 防护措施

1、无效连接监视释放
这种方法不停的监视系统中半开连接和不活动连接，当达到一定阈值时拆除这些连接，释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉，“伤敌一千，自损八百”。
2、延缓TCB分配
SYN Flood关键是利用了，SYN数据报文一到，系统立即分配TCB资源，从而占用了系统资源，因此有俩种技术来解决这一问题：
2.1、Syn Cache技术
这种技术在收到SYN时不急着去分配TCB，而是先回应一个ACK报文，并在一个专用的HASH表中（Cache）中保存这种半开连接，直到收到正确的ACK报文再去分配TCB。
2.2、Syn Cookie技术
Syn Cookie技术则完全不使用任何存储资源，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源。
2.3、使用SYN Proxy防火墙
原理：对试图穿越的SYN请求进行验证之后才放行

二、TCP连接断开的4次挥手

为什么要4次挥手？

还是记住这是全双工通信！一般来说都是客户端发起的连接断开请求，这要结合实际来理解！客户端在发送完自己的TCP请求后，自己就没有东西再发送了，所以会请求断开TCP连接，这一步的意义是什么？客户端想说：我已经没有数据要发给你了，我先断开我到你的发送数据的通道了，但是我还是可以接受你的数据的！服务器收到客户端的断开请求后，就同意了，但是服务器的内容可能还没发送完呢？服务器继续发送响应内容给客户端，发送完了之后，服务器也没东西再发了，所以也发送连接断开请求，这告诉客户端，我也没东西发送了，我要关闭连接了。客户端收到后，回复服务器，我知道了，那我也关了！当服务器接收到客户端的回复了，就关闭了TCP连接。客户端如果在2个最大段生命周期没有收到服务器第3次挥手的确认报文，说明服务器收到了刚才我发的第4次挥手的报文，也关闭了TCP连接。

三、参考文章

总结的很好，分析地很正确

四、HTTP1.0和1.1

目前大部分浏览器都是使用HTTP1.1协议。

1、HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理。

HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent connection。在同一个tcp的连接中可以传送多个HTTP请求和响应。多个请求和响应可以重叠，多个请求和响应可以同时进行。而且加入了更多的请求头和响应头(比如HTTP1.0没有host的字段)。

在1.0时的会话方式：

1. 建立连接
2. 发出请求信息
3. 回送响应信息
4. 关掉连接

   HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。

请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。 HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容。

2.HTTP 1.1增加host字段

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。

HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。

参考链接： 参考文章