最近公司项目不多，闲着也来写写文章，复习一下基础知识。之前也写了好几片文章，苦于自己不太会玩标题党，结构内容也不生动，没什么点击量，希望慢慢总结的写，提高水平，给大家带来好的内容，废话不多说。下面进入正题。

说道TCP/IP、HTTP两个词，我估计各位应该没有人不知道，多多少少听到一些，如果您是网络专业的专家或熟知这些内容，就请您轻拍、路过。

TCP/IP 名词解释

IP（Internet Protocol）协议的英文名直译就是：因特网协议，它可以根据网络情况，将要传输的数据，分为不同大小的包、固定的格式，在源地址和目的地址之间传送。就好比现实生活中，我们有一批货物要从北京发送到广州，运输时我们把货物包装成一个个的包装箱后，然后进行运输，在这里IP协议就好比规定了包装箱的尺寸和包装方法。

IP的头部只有16位首部校验和，只能对ip头信息进行数据校验，但对数据本身是没有校验的。
TCP （Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议。IP协议也有一些缺陷（传输不可靠也就是不提供点到点的传输确认、对数据没有完整性校验、不能重发和流量控制）。继续用传输货物的比喻，IP协议就好比货是打包发走了，但广州方面收没收到货物不管，货物是否完好无损不管。TCP协议在IP协议的基础上提供了可靠地面向对象的数据流传输服务的规则和约定。简单说，就是发送一个数据包，我就要确认对方有效，完整的收到。
TCP的头部16位校验和是对数据的完整性校验。

可以设成1 or 0，用来应答，它们分别表示的含义如下：

TCP/IP四层模型与OSI七层模型的对应关系

TCP是有连接的，两台主机在进行数据交互之前必须先通过三次握手建立连接；而UDP是无连接的，没有建立连接这个过程。
TCP是可靠的传输，TCP协议通过确认和重传机制来保证数据传输的可靠性；而UDP是不可靠的传输。
TCP还提供了拥塞控制、滑动窗口等机制来保证传输的质量，而UDP都没有。
TCP是基于字节流的，将数据看做无结构的字节流进行传输，当应用程序交给TCP的数据长度太长，超过MSS时，TCP就会对数据进行分段，因此TCP的数据是无边界的；而UDP是面向报文的，无论应用程序交给UDP层多长的报文，UDP都不会对数据报进行任何拆分等处理，因此UDP保留了应用层数据的边界。

第一次握手（绿区箭头1）：客户端想与服务器建立连接传送数据，客户端调用向服务器发送TCP报文请求，SYN = 1, Sequence Number = x; 然后，客户端进入SYN_SEND状态，等待服务器的确认。
第二次握手（绿区箭头2）：正在处于LISTEN状态的服务器端接受到客户端发来的SYN报文后，表示我收到了你的请求，我可以与你建立连接收发数据，服务器会发送返回确认信息，这个信息是Acknowledgment Number = x + 1(Sequence Number + 1)；同时包含服务器端的SYN请求信息：SYN = 1, Sequence Number = y; 一并发送给客户端，此时服务器进入SYN_RECV状态。
第三次据手（绿区箭头3）：处于SYN_SEND状态的客户端，接收到服务器发来的SYN+ACK标识位的报文后，将Acknowledgment Number = y + 1，的确认报文回发给服务器，表示我知道服务器端你已经收到我发送的第一次握手请求。然后进入ESTABLISHED状态。
服务器端收到第三次握手后，进入ESTABLISHED状态。到此完成TCP三次握手，可以接下来收发数据。

第一次挥手（橙区箭头一）：客户说数据传完啦，我想和你断开连接，然后发送TCP报文，内容为：FIN = 1, Sequence Number = x + 2, ACK = Y + 1; 然后客户端进入FIN_WAIT_1状态；
第二次挥手（橙区箭头二）：服务器收到第一次挥手的请求后，说我收到了，回复：ACK = x +3; 然后服务器进入CLOSE_WAIT状态;
客户端收到以后状态改为FIN_WAIT_2。
第三次挥手（橙区箭头三）：服务器向客户端发送：FIN = 1, Sequence Number = y + 1; 然后服务器进入LAST_ACK状态;
第四次挥手（橙区箭头四）：客户端收到服务器发送的FIN报文，然后向服务器发送：ACK = Y + 2; 然后然后客户端就进入TIME_WATI状态，服务器收到以后就关闭连接，此时，客户端还会等待2MSL后，依然没有收到服务器端任何回复，就表示服务器端正常关闭，那客户端也就关闭了。

因为每个方向都需要一个FIN和ACK，当一端发送了FIN包之后，处于半关闭状态，此时仍然可以接收数据包。
在建立连接时，服务器可以把SYN和ACK放在一个包中发送。
但是在断开连接时，如果一端收到FIN包，但此时仍有数据未发送完，此时就需要先向对端回复FIN包的ACK。等到将剩下的数据都发送完之后，再向对端发送FIN，断开这个方向的连接。
因此很多时候FIN和ACK需要在两个数据包中发送，因此需要四次握手

伪装的IP向服务器发送一个SYN请求建立连接，然后服务器向该IP回复SYN和ACK，但是找不到该IP对应的主机，当超时时服务器收不到ACK会重复发送。当大量的攻击者请求建立连接时，服务器就会存在大量未完成三次握手的连接，服务器主机backlog被耗尽而不能响应其它连接。即SYN泛洪攻击。
防范措施：
1. 降低SYN timeout时间，使得主机尽快释放半连接的占用。
2. 采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文。
3. 在网关处设置过滤，拒绝将一个源IP地址不属于其来源子网的包进行更远的路由。
4. 当一个主机向服务器发送SYN请求连接，服务器回复ACK和SYN后，攻击者截获ACK和SYN。然后伪装成原始主机继续与服务器进行通信。

下一篇计划《HTTP协议干活面试》。