串联知识点：从TCP，到http请求，再到三次握手和四次挥手肥宅慌了，TCP都不知道是什么，谁给我的勇气来看这个文章的。

在阅读这个TCP为啥要3次握手和4次挥手？握两次手不行吗？文章的时候，突然想起，TCP是啥？

肥宅慌了，TCP都不知道是什么，谁给我的勇气来看这个文章的。

所以我们就从TCP开始讲起吧！

（写到最后发现快一万字了，七七八八的扯了很多知识点，下次复习的时候还会想看这篇文章吗..）

了解TCP

TCP/IP协议族

我们通常使用的网络都是在TCP/IP协议族的基础上运作的。

既然计算机和网络设备之间要相互通信，那么通信的时候就需要规则对吧。比如哪边发起通信，用什么语言通信，这些都是需要一些规则来规定的。这些规则就是协议。

协议里面会有各种各样的内容，比如电缆的规格，双方建立通信的顺序，Web页面显示需要处理的步骤等等。

相似协议的都被归为一族，而TCP/IP协议族就是互联网相关联的协议的集合，也有说法认为TCP/IP是TCP和IP这两种协议，还有一种说法认为TCP/IP是在IP协议通信过程中使用到的协议族的统称。

TCP/IP的分层管理

TCP/IP协议族按层次分为：应用层，传输层，网络层，数据链路层。

为什么要给人家分层嘞？

假设整个协议都是一个整体，没有进行层次化的设计，那么当协议中某一部分需要进行调整的时候，那就需要对整个协议进行修改。但进行分层解耦之后，每一层的内容相对独立，互不影响。需要进行变更的时候只需要针对某一层的协议内容进行做变动，不会影响到其他几层的内容。
层次化对设计也有好处，每层只用好好完成自己的任务就可以了。处于应用层上的应用可以只考虑自己的任务，也不用管对方在那个地方，对方的传输线路是什么样的，能不能确保传输送达这些乱七八糟的问题。

TCP/IP协议族的层次

应用层

应用层决定这次通信的应用类型，比如说FTP（file transfer protocol文件传输协议）、DNS（domain name system域名系统）、SMTP（simple mail transfer protocol 简单邮件传输协议）等等，同时HTTP协议也属于应用层的范围。通俗来讲，应用层决定这一次通信要干嘛。比如FTP用来共享网络文件，DNS用来转换域名和IP地址（事实上他是为其他应用层协议工作的），SMTP用来传递系统之间的邮件信息，HTTP用来从万维网服务器传输超文本到本地浏览器。
传输层

传输层提供两台计算机之间的数据传输，根据应用程序的不同需求，传输层需要有两种不同的协议：面向连接的TCP协议和无连接的UDP协议。当传输层采用TCP协议的时候，尽管下面的网络是不可靠的，他也会尽最大的努力服务，保证通信的可靠。但是如果采用了UDP协议，整个通信依然是不可靠的。
网络层

网络层用来处理网络上流动的数据包，在这一层中规定了通过什么样的路径（传输路线）到达对方的计算机，把数据包传给对方。

当我们与对方的计算机之间会通过多台计算机或网络设备来传输信息的时候，网络层能够在众多的选项内选择一条合适的传输路线。
数据链路层（又名链路层，网络结构层）

数据链路层用来处理网络的硬件部分，包括控制操作系统，硬件设备等等。硬件上的范畴均在数据链路层的作用范围之内。

TCP是干啥的？

TCP是为了在不可靠的互联网上提供可靠的端到端字节流通信而专门设计的一个传输协议。

这句话有很多的关键词：

不可靠的互联网

在互联网上，互联网的不同部分可能有截然不同的拓补结构带宽、延迟等其他参数，TCP设计的目标就是希望能够动态的适应互联网的这些特性，而且能面向各种故障。
可靠的通信

不同主机的应用层之间经常需要可靠的，像管道一样的连接，但是IP层只是提供不可靠的包交换，所以可靠的连接就由TCP来完成。

应用层会向TCP层发送数据流，TCP会把数据流分成适当长度的以报文段为单位的数据包，然后把数据包传输给IP层，IP层通过网络将包传送给接收端的TCP层。

TCP为了保证不丢包，就会给每个包都标上序号seq，接收端成功接受到包的时候会返回一个相应的ACK。如图：
字节流通信

"流"：流入到进程或从进程流出的字节序列。

"面向字节流"：虽然应用程序（应用层）和TCP的交互是一次一个数据块（大小不等），但TCP把可以把所有的数据看成是一连串的无结构的字节流，可以随便分割。

然后TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它切短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

总的来说就是，TCP不关心本地发送给自己的内容是啥（反正都是字节），他就只管切，他会先看看现在的网络拥塞程度啥的，来决定切多少。他关心时序，先发给自己的肯定先编号，后发的后编号，保证传输的顺序就行。

当然，接收方的应用程序必须有能力识别收到的字节流，然后把他们还原成有意义的应用层数据（按照编号顺序排号就能还原啦）。

TCP的其他特点：

是面向连接的传输层协议。

应用程序再使用TCP之前必须要建立TCP连接。传送数据完毕之后必须释放已经建立的TCP连接。
每一条TCP连接只能是一对一（点对点）的。
TCP提供可靠交付的服务。用TCP连接传送的数据无差错，也不会丢失（丢失会重传），不重复（重复了会删掉），而且按序到达（刚才第三点已经讲过了）。
TCP提供全双工通信。允许通信双方的应用进程在任何时候发送数据。TCP连接的两端都会有发送缓存和接受缓存。

发送的时候，应用程序会把数据发送给TCP的缓存，然后应用程序就自己去干自己的事了，而TCP会在合适的时候把数据发送出去。

接收的时候，TCP会把收到的数据放入缓存，应用程序想读取就读取。

顺便讲讲UDP？

UDP在传输数据之前不需要建立连接，也就是说收到UDP发送的报文之后不需要给出任何的确认（所以他不怎么可靠嘛，没有给出确认怎么知道有没有传到，说明他根本就不管你有没有传到）。而TCP提供面向连接的服务，在传送数据之前必须建立连接，传送结束之后要释放连接。因此TCP的开销要比UDP的大很多，比如确认，流量控制，计时器，连接管理等等，都会占用很多的资源。

当应用层协议上使用DNS，SNMP等协议的时候，传输层会使用UDP。但是当应用层上使用SMTP，HTTP，FTP的时候会使用TCP协议。

UDP的主要特点是：

UDP是无连接的（这点一开始已经讲过了）。
UDP尽最大努力交付，不保证可靠交付，所以不需要维持复杂的连接状态。
UDP是面向报文的，发送方的UDP对于应用层发过来的报文，直接添加个首部就交给IP层了。不拆分也不合并。也就是说应用层交给UPD什么，UDP就照样发送，一次发一个。而接收方的UDP，对IP层交上来的数据包直接去掉首部就完事了。

反正UDP每次都会交付一个完整的报文，因此应用层要选择大小合适的报文。如果报文太长了，UPD把报文交给IP层，然后会由IP层来分片，降低了IP层的效率。

如果报文太短了，UDP把报文交给IP层之后，IP数据报的首部在整个数据报中占的比重就比较大。这也降低了IP层的效率。
UPD没有拥塞控制，所以网络上出现的拥塞不会导致源主机的发送速率变低。发送速度在某些情况下是很重要的，比如视频，IP电话啥的。都要求源主机以恒定的速度发送数据，而且允许丢失一些数据，UDP正好符合这样的要求。
UDP支持一对一，一对多，多对一和多对多的交互通信。
UDP的首部开销比较小，只有8个字节，比TCP的20个字节的首部要短。

要注意的是，虽然某些实时应用需要UDP，但是在很多源主机都同时向网络发送高速率的实时视频流的时候，网络就有可能会发生拥塞，结果大家都无法正常接收。因此不使用拥塞控制的UDP有可能会引起严重的拥塞问题。

还有一些UDP的实时应用，要对UDP的不可靠传输进行适当的改进，减少数据的丢失，比如向前纠错或重传已丢失的报文等等。

TCP和DCP的区别就不再说啦，上面这些都是区别（感觉他们就没啥相似的）。

捋一遍http请求的过程

有了上面的基础，我们可以来捋一遍http请求过程啦。

当我们在web浏览器的地址栏中输入： www.baidu.com，然后回车
应用层开始工作啦，先进行DNS域名解析：
1. 浏览器内部代码将url进行拆分。
2. 解析域名。
  
  浏览器会一层一层的找，看看有哪里保存到该域名对应的IP，如果有就向IP地址发送请求。如果没有就继续往下找。
  1. 首先搜索浏览器自身的DNS缓存
  2. 如果没有找到，浏览器会搜索系统自身的DNS缓存
  3. 如果没有找到，浏览器会去找本地的hosts文件
  这时候如果还没找到，就去域名服务器中找，如果找到了就将域名解析成对应的服务器IP地址发回给浏览器。
  
  解析完之后得到了ip，应用层就会客户端发送HTTP请求。
传输层开始工作啦。为了传输方便，在传输层（TCP协议）把从应用层处收到的数据（HTTP请求报文）分割成以报文段为单位的数据包进行管理，然后在各个报文上打上标记序号和端口号后传输给网络层，方便服务器接收时能准确地还原报文信息。

为了保证传输的安全可靠，这时会进行三次握手。这里先不展开讲，等下我们再详细说。
到了网络层以后，就是IP协议的主场啦！IP协议的作用是把TCP分割好的各种数据包传送给接收方。要保证确实传送到对方那里需要满足各种条件。其中有两个很重要的条件是IP地址和MAC地址。

那么IP地址已经在应用层通过dns解析出来了，就差MAC地址了。这时就会采用ARP协议，他会通过通信方的给的IP地址查出目标MAC地址。

找到MAC地址之后，就在报文中添加上地址，转发给链路层。

实际上，我们很少会在局域网内通信，所以我们一般会把数据包传到路由器，由路由器进行中转。所以一般流程都是这样的：先用ARP查出路由器的MAC地址，然后把数据包传给路由器，然后路由器一看，哦！原来是发往这个IP地址的，然后就在路由表中查查查，看看下一站应该发到哪里去，他查到的是一个IP地址，这个IP地址要用ARP翻译成MAC地址，才能把数据发到下一个路由器。到了下一个路由器之后又检查IP，然后又找到下一个路由器的MAC地址，然后又传递数据..直到数据包传递到最终目标。
数据链路层进行数据传输。由数据链路层的网桥、交换机根据mac地址进行端口转发，再由物理层的中继器、集线器进行信号传输放大等。这时，客户端发送请求的阶段结束。
服务器接收数据

接收端的服务器在链路层接收到数据包，再层层向上消除首部信息直到应用层。这时候才算真正接受到客户端发送过来的HTTP请求。
服务器响应请求

服务接收到客户端发送的HTTP请求后，查找客户端请求的资源，并返回响应报文。

IP地址&MAC地址

晕..越讲越偏离主题了。这里随便看看吧，都是直接引用了别人的文章，不想看的跳过也可以~反正和主题的关系不大，只是加深理解。

IP地址指明节点被分配到的网络位置，而MAC地址是指网卡所属的固定地址（也叫局域网地址，物理地址，是一个用来确认网络设备位置的地址）。MAC地址用于在网络中唯一标示一个网卡，一台设备若有一或多个网卡，则每个网卡都需要并会有一个唯一的MAC地址。MAC地址是数据链路层使用的地址，IP地址是网络层及其以上层使用的地址。

看到了两篇写得很通俗易懂很好玩的文章，但是其中一篇不允许转载，所以我就直接把两篇都贴出来了，感兴趣的可以去看看~

为啥有了IP还要用MAC?

为啥有了MAC还要用IP？

三次握手

说实话，我本来只打算写三次握手的，但是TCP洋洋洒洒写了两千多字，好尴尬，默默把标题给改了。

首先看看一些标识符和一些规则，我觉得还挺重要的，第一次看到三次握手的时候觉得哇这么多乱七八糟的符号好厉害的样子，看了好几次也没看懂。搞懂他们的意思和规则之后就比较好理解了。

一些标识符和一些规则

标识符

SYN（synchronous）

请求建立连接（我是这么记的，sync是同步的意思，所以SYN是请求同步的握手信号）
ACK（acknowledgement）

确认字符，如果接收方成功的接收到数据，那么会回复一个ACK数据，表示发来的数据已确认接收无误。
FIN（finish）

结束，当FIN=1表示此报文段的发送方已经发送完毕，并要求释放链接。
PSH（push）传送
RST（reset）重置
URG（urgency）紧急
seq（Sequence Number）

序列号，占4个字节，表示报文段携带数据的第一个字节的编号。

由于TCP是面向字节流的，在一个TCP连接中，字节流中的每一个字节都按照顺序编号。

例如，一段报文的序号值是301，而携带的数据共有100字段，显然下一个报文段（如果还有的话）的数据序号应该从401开始。

为什么他是随机的呢？

首先，假设A和B之间有一个TCP连接，那么这个连接通常是由A和B的2个ip地址，2个端口号构成的四元组。

这时候，只要A发送了一个TCP报文段，报文段的四元组和序号和之前的TCP连接相同的话，都会被B确认。

如果seq是固定的，然后一些恶意攻击者去选择合适的序号，ip地址和端口的话，就能伪造出一个TCP报文段，从而打断正常的TCP连接。但是通过算法来随机生成序号就难以被猜出，减少恶意攻击行为。

而且如果用固定的序号，很容易发生数据报之间的冲突。比如A和B之间建立了连接，然后A以序号1发出了一个数据报，但是在网络中滞留了很久。这时候A又突然故障重启了，又重新和B建立了连接，还是用之前的序号1愉快的通信着。这时，之前那个一直滞留的数据报终于到达了B，B会误认为这是新连接发过来的数据报，然后就收了。这样会导致数据乱序。
ack（Acknowledgment Number）

确认号，占4个字节，期待收到对方下一个报文段的第一个数据字节的序号。

例如，B收到了A发送过来的报文段，其序列号seq是1，而数据长度是100字节，这表明B正确的收到了A发送的到序号从1到100为止的数据。因此，B期望收到A的下一个数据序号是100+1，于是B在发送给A的确认报文段中把确认号置为101

一些规则

TCP规定，SYN报文段不能携带数据，但是需要消耗一个seq序列号。这就是我们每次看到SYN的时候后面都会跟着一个seq的原因。
ACK报文段可以携带数据，但是如果不携带数据就不消耗序号。但是人家还是要带个确认号滴。如果要携带数据，后面就会跟这个seq。
FIN报文段即使不携带数据也要消耗一个序号，所以FIN后面也会跟着一个seq。

三次握手的过程

服务器准备：创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态

客户端准备：也创建传输控制块TCB。

第一次握手：

客户端发出建立连接的报文，并且进入SYN-SENT（同步已发送状态）。

其中SYN=1，随机生成一个初始序列号seq=x。表示想要和服务端建立连接。
第二次握手：

收到请求报文之后，如果同意连接，服务端会发出建立连接和确认报文，因此SYN=1，ACK=1。由于含有ACK所以带上一个确认号ack=x+1，由于含有SYN所以随机生成一个序列号seq。这时服务器进入SYN-RCVD（同步已收到）状态。

看到这里我就懵了：啥？为什么是x+1？按照ack的定义来看，不是应该是x+报文长度+1嘛？百度一查：

在TCP建立连接时三次握手的时候：
```
[SYN] Seq=0, Len=0
-------------------------------->

[SYN, ACK] Seq=0, ACK=1, Len=0
<--------------------------------

[ACK] Seq=1, Ack=1, Len=0
-------------------------------->
```
由于SYN不能携带数据，所以包的Len=0，那为什么ack会变成上个包的seq+1，而不是seq呢？

服务端为了确认客户端的SYN，会将LEN+1作为ACK数值。这样，每发送一个SYN，序列号就会加1。如果有丢失的情况，则会重传。

就是说当报文中有SYN或者FIN的时候，就算没有携带数据，服务器端也要在确认号中通过上个包的seq+1的方式来表示确认收到。其他几次握手挥手也是同样道理。
第三次握手：

客户端发送确认报文，因此报文中ACK=1，ack=y+1。

此时，TCP连接建立，然后客户端进入ESTANBLISHED（已建立连接）状态。

客户端：表示我已经准备好了，可以向我发送数据了。

之后服务端收到确认报文之后也进入了ESTANBLISHED状态，双方可以开始通信了。

三次握手的一些问题

TCP为什么采用三次握手，两次可以吗？

如果客户端发送了第一个请求连接，而且没有丢失，只是在网络上滞留了。本来这是一个失效的报文，但是服务端不知道呀，他还是正常的发回一个确认报文，然后建立起链接。但是实际上我们这边太久等不到服务器的回应，就已经认为这个连接失效了，有可能会发起第二次连接，也有可能不连接了。反正就是不会再往这个连接上边传输东西了。但是服务器他还是不知道呀，他就傻傻的等着等着，等着你给他传东西，等着你关闭连接。这就造成了资源的浪费。

那如果我们使用了三次握手，服务器发回确认报文给我们，我们不理睬他，他就知道连接没有建立成功，那他也不理你了。

三次握手过程中可以携带数据吗？

TCP协议建立连接的三次握手过程中的第三次握手允许携带数据。

第一次不可以携带数据，也不可以先将数据缓存下来，等握手成功再提交给应用程序，这样会放大SYN FLOOD攻击（后面会讲）。如果有人要恶意攻击服务器，那他每次都在第一次握手中的SYN报文中放入大量的数据，然后疯狂重复发SYN报文的话，这会让服务器花费很多时间、内存空间来接收和处理这些报文。也就是说，第一次握手可以放数据的话，会让服务器更加容易受到攻击。

但是能够发出第三次握手报文的主机，肯定接收到第二次握手报文，因为伪造IP的主机是不会接收到第二次报文的。所以，能够发出第三次握手报文的，应该是合法的用户。

客户端突然挂了怎么办？

正常连接的时候客户端突然挂掉，如果没有措施去处理，客户端和服务器端就会长时期空闲。所以我们需要一个活计时器（SYN Timeout），服务器一收到客户端的信息就把计时器复位，超时时间一般设为两个小时，如果服务器两个小时了还没收到客户的信息，就会发送探测报文段，如果每隔75秒发送一个报文段，一共发送了十个报文段之后还没有响应，就认为是客户端出现了故障，终止连接。

四次挥手

服务端和客户端之间如果有谁不想通信了，就可以发出断开连接的请求。

第一次挥手

客户端进程发出连接释放报文，所以FIN=1，他要消耗序列号，所以后面有跟了一个随机生成的序列号seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1）。

这时客户端进入FIN-WAIT-1（终止等待1）状态，
第二次挥手

服务端收到FIN之后，如果同意断开就发回一个ACK确认，ACK=1。根据规定，确认号ack=u+1，然后带上一个随机生成的序列号seq=v。

这个时候服务端进入LOSE-WAIT（关闭等待）状态。这时候TCP处于半连接状态，虽然说客户端已经没有东西要发送了，但是服务端可能还有东西没传，所以服务端要传东西的话客户端还是需要接受的。这个过程还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

而客户端那边，一收到服务器确认请求之后就进入FIN-WAIT-2（终止等待2），等待服务器发来最后要发送的数据，还有连接释放的报文。
第三次挥手

服务端发送一个FIN到客户端，然后关闭客户端的连接。因此FIN=1，ack还是原来的u+1。服务器可能在半关闭状态中又发送了一些数据，就不用原来的seq=v了，假定seq=w。

这时候服务器就进入LAST_ACK（最后确认）状态，等待客户端确认。
第四次挥手

客户端要确认自己全部接受数据了，所以发出确认报文：ACK =1，ack=w+1。序列号是之前的ack确认号也就是seq=u+1。

然后客户端就进入了TIME-WAIT（时间等待）状态。这个时候的TCP连接还没有释放，他要经过2∗MSL（最长报文段寿命）的时间后，客户端撤销TCB之后才进入CLOSED状态。

而服务器那边，只要收到了客户端发出的确认就立即进入CLOSED状态。可以看到，服务器结束TCP连接的时间要比客户端早一些。

四次握手的一些问题

为什么是4次挥手呢？

因为是客户端提出的要关闭连接，如果你马上就同意了那也太突兀了吧。客户端突然提出关闭的话，应该要留给服务端一些反应时间，他可能还有一些数据没发完。

所以服务端要先发出ACK确认报文，确认已经收到了客户端发出的请求，相当于是在告诉客户端：哦，我知道了，但是等一下！我还有些东西要给你。然后刷刷刷发数据。

然后我们传递完东西之后，才能发送FIN报文来正式关闭连接。相当于是告诉客户端：我发完了，可以关闭了。

然后这还没完，你收没收到我发的数据要告诉我一声呀，没收到的话我还要再发呢。所以客户端还要给服务端发一个确认报文，表示我真的收到啦！

为什么要等待2MSL呢？

2MSL是时间等待计时器（TIME-WAIT timer）设置的事件，而MSL是最长报文段寿命。任何报文在网络上存在的最长的最长时间，超过这个时间报文将被丢弃。一般建议设置为2分钟，但是对于现在的网络可能两分钟有点长，所以也允许使用更小的MSL值。

现在以2分钟为例，那么客户端进入TIME-WAIT状态之后要等个四分钟才能进入到CLOSED状态，才能开始下一段新的连接。然后客户端撤销相应的传输控制块TCB，才算结束这一次的TCP连接。

等待2MSL的理由有两个：

为了保证客户端发送的最后一个ACK报文段能够到达服务端。

因为这个ACK报文段有可能会丢失，导致处在LAST-ACK状态的服务端收不到确认，他就等啊等啊等，等了一定的时间（等待时间应该要大于MSL，才能确认丢包），重传FIN-ACK的报文段，这样的话客户端就能在2MSL等待时间内收到这个重传的报文段，然后客户端重传ACK报文段，又重新启动计时器。最后客户端和服务端才正常进入CLOSED状态。

那么如果客户端不等待，发完ACK就关闭连接，当这个报文丢失的时候，服务端重传FIN-ACK报文段，客户端就收不到了，也就不传ACK了，那服务端就没办法进入关闭状态了。服务端一定要拿到客户端给他发来的确认报文ACK才能关闭。
防止已经失效的链接请求出现在本连接当中。

如果在上一次连接的时候，有一些数据滞留在网络中，然后又在新连接建立后到达服务端，那么服务端会认为那些延迟数据是属于新连接的，数据包就会发生混淆。

客户端发送完最后一个ACK报文段之后，再经过2MSL时间，就可以让本连接持续的时间内产生的所有报文段都从网络中消失（因为报文最长寿命只有MSL）这样就可以使下一个新连接中不会出现旧的连接请求报文段。

SYN（洪水）攻击

洪水攻击原理

如果客户端发送一个SYN包给服务端之后挂了，然后服务器返回一个SYN-ACK，但是一直收不到客户端的ACK确认包，这时候处于半连接状态，所以服务器会一直等待你客户端发ACK过来。如果有大量的这种半连接状态的无效连接，会耗尽服务端的SYN连接队列的位置。那么正常的连接就没位置了，会被拒绝处理。

好在服务端有一个超时时间，如果过了这个时间服务器就断开连接不等你了。目前，LINUX下默认会重发5次SYN-ACK包，每次发送包的时间间隔为1s, 2s, 4s, 8s, 16s，第五次发出包之后还要等32s才知道第五次有没有超时。

所以总共需要63s，差不多一分钟的时间，TCP才会断开连接。那么就给攻击者一个攻击服务器的机会，攻击者能够在短时间内发送大量的SYN包给服务器，用于耗尽服务器的SYN队列。

什么是 SYN 攻击

SYN攻击指的是，在短时间内伪造大量不存在的IP地址，向服务器不断地发送SYN包，服务器回复确认包并等待客户的确认。这时候连接半开，吞下服务器资源。由于阻止服务攻击，合法用户尝试连接到服务器但被拒绝。

由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，导致目标系统运行缓慢，严重者会引起网络堵塞甚至系统瘫痪。SYN攻击是一种典型的DoS攻击。

如何检测 SYN 攻击？

在服务器上看到大量的半连接状态时，而且源IP地址是随机的，基本上就是SYN攻击。

如何防御 SYN 攻击？

SYN攻击不能完全被阻止，除非将TCP协议重新设计。我们所做的是尽可能的减轻SYN攻击的危害，常见的防御SYN攻击的方法有如下几种：

缩短超时（SYN Timeout）时间
增加最大半连接数
过滤网关防护SYN
cookies技术

最后：这个东西写了两天，因为知识点真的太多了，写着写着就发现一个新的知识点，写到最后已经没力气思考了。。好好反思一下才行。。

参考文章：