OSI七层网络模型	TCP/IP四层概念模型 ?	对应网络协议
应用层（Application）	应用层	HTTP、TFTP,?FTP, NFS, WAIS、SMTP
表示层（Presentation）		Telnet, Rlogin, SNMP, Gopher
会话层（Session）		SMTP, DNS
传输层（Transport）	传输层	TCP, UDP
网络层（Network）	网络层	IP, ICMP, ARP, RARP, AKP, UUCP
数据链路层（Data Link）	数据链路层	FDDI, Ethernet, Arpanet, PDN, SLIP, PPP
物理层（Physical）	数据链路层	IEEE 802.1A, IEEE 802.2到IEEE 802.11

二、TCP协议连接管理

2.1 TCP协议和TCP/IP协议的关系

TCP/IP（Transmission Control Protocol/Internet Protocol，传输控制协议/网际协议）是指能够在多个不同网络间实现信息传输的协议簇。TCP/IP协议不仅仅指的是TCP 和IP两个协议，而是指一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇，只是因为在TCP/IP协议中TCP协议和IP协议最具代表性，所以被称为TCP/IP协议。

2.2 TCP和HTTP协议

HTTP 通信由 TCP/IP 承载的。客户端应用程序可以打开一条 TCP/IP 连接，连接到可能运行在世界任何地方的服务器应用程序。一旦连接建立，在客户端和服务器的计算机之间交换的报文就永远不会丢失、受损或失序。

2.3 三次握手

三次握手是为了保证客户端和服务端之间消息传输的可靠性，确保传输数据之前建立可靠连接。为了确保数据能够正确分发，TCP用一种叫做TCB，也叫传输控制块的数据结构把发给不同设备的数据封装起来，我们可以把该结构看做是信封。一个TCB数据块包含了数据发送双方对应的socket信息以及拥有装载数据的缓冲区。在两个设备要建立连接发送数据之前，双方都必须要做一些准备工作，分配内存建立起TCB数据块就是连接建立前必须要做的准备工作。

TCP建立连接需要三次握手，SYN是发送标志位，ACK是确认标志位.

（0）准备工作
最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态

（1）一次握手：
TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x。此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。

（2）二次握手：
TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。ACK为1表示确认号有效，为0表示报文中不包含确认信息

（3）三次握手：
TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。当服务器收到客户端的确认后也进入ESTABLISHED（已建立连接）状态，此后双方就可以开始通信了。

2.4 四次挥手

数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于established（表示连接已经建立）状态，然后客户端主动关闭，服务器被动关闭。

（1）TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。

（2）服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和 SYN一样，一个FIN将占用一个序号。

（3）服务器关闭客户端的连接，发送一个FIN给客户端。

（4）客户端发回ACK报文确认，并将确认序号设置为收到序号加1。

三、TCP协议的可靠性

3.1 为什么需要三次握手

客户端和服务端通信前要进行连接，3次握手的作用就是双方都能明确自己和对方的收、发能力是正常的。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。

第一、二次握手后，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。而在第三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送能力是正常的。而客户端的接收能力也是正常的。

3.2 为什么需要第三次确认

主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，此时客户端以为服务器没有收到，重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

3.3 为什么需要四次挥手

建立连接的时候，服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。 关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必已经将全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

3.4 为什么客户端挥手最后要等待2MSL

MSL（Maximum Segment Lifetime）是指报文段最长寿命，TCP允许不同的实现可以设置不同的MSL值。

去向ACK消息最大存活时间（MSL) + 来向FIN消息的最大存活时间(MSL)。这刚好就是2MSL( Maximum Segment Life)。

?第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，等待2MSL时间，客户端就可以放心地释放TCP占用的资源、端口号。如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的TCP报文可能与新TCP连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的TCP连的活跃报文全部死翘翘，2MSL时间可以满足这个需求。

3.5 连接建立后客户端出现故障怎么办

TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

两个小时的时间过长，连接断开通常是由上层应用维护。

3.6 拥塞控制和超时重传

TCP传输是分段的，一个HTTP报文会被操作系统切成多个MSS（Maximum Segment Size）大小的段，直到接收端接受到完整的报文为止。在此过程中，报文分段按照顺序进行发送，每个报文段在发送时，会做顺序编号，以便能够完整正确地组装。

MSS：Maximum Segment Size 最大报文段长度，是TCP协议的一个选项，用于在TCP连接建立时，收发双方协商通信时每一个报文段所能承载的最大数据长度（不包括文段头）。如果MSS选项数据为512，则表示该报文段的发送方可以处理的最大报文段长度为512字节（不包括TCP与IP协议头长度）。主机一般默认MSS为536字节。

TCP 的数据是通过名为 IP 分组（或 IP 数据报）的小数据块来发送的，IP属于网络层协议，TCP传输层协议建立在IP协议之上。HTTP 就是应用层协议，?其安全版本 HTTPS 就是在 HTTP 和 TCP 之间插入了一个（称为 TLS 或 SSL的）密码加密层。

将TCP与UDP这样的简单传输协议区分开来的两种协议不同的传输数据的质量。TCP对于发送数据进行跟踪，这种数据管理需要协议有以下两大关键功能：

可靠性：保证数据确实到达目的地。如果未到达，能够发现并重传。
数据流控：管理数据的发送速率，以使接收设备不致于过载。

要完成这些任务，整个协议操作是围绕滑动窗口确认机制来进行的。

因为TCP需要保证报文传输的顺序并且确认收到，所以每次发消息都需要ACK确认，但是一个报文段确认一次又需要大量的网络开销，能不能批量确认呢？如果客户端向服务端一次性发送过多的数据包，超过了服务端的处理能力，导致了网络拥塞又该怎么办？

之前讲过高并发三大利器的限流，这里的滑动窗口协议和其中的滑动窗口算法类似，只是应用场景不同。

滑动窗口协议（Sliding Window Protocol）是TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认。因此该协议可以加速数据的传输，提高网络吞吐量。

下面以一张图来介绍下TCP的滑动窗口协议：

如果我们在任一时间点对于TCP传输这一过程做一个“快照”，那么我们可以将TCP缓冲区
中的数据分为以下四类，并把它们看作一个时间轴：

已发送已确认：数据流中最早的字节已经发送并得到确认。这些数据是站在发送设备的角度来看的。
已发送但尚未确认：已发送但尚未得到确认的字节。发送方在确认之前，不认为这些数据已经被处理。
未发送而接收方已Ready：设备尚未将数据发出，但接收方根据最近一次关于发送方一次要发送多少字节确认自己有足够空间。发送方会立即尝试发送。
未发送而接收方Not Ready：由于接收方not ready，还不允许将这部分数据发出。

?上图中窗口的固定大小为6个报文段，每个报文段都有一个顺序编号，每次已发送未确认的消息被确认之后，窗口向后移动，这属于正常的过程。但还有一种情况如下图所示：

当滑动窗口里的报文都发送出去了，但窗口最开始的报文迟迟得不到确认（也可能网络原因没有发送出去），那窗口里存在的都是未确认的消息，就不会往后移动了，这个时候就需要等待，触发超时重传。

超时重传的原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。

影响超时重传机制协议效率的一个关键参数是重传超时时间（RTO，Retransmission TimeOut）。RTO的值被设置过大过小都会对协议造成不利影响。

RTO设长了，重发就慢，没有效率，性能差。
RTO设短了，重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。
?

在 Unix 以及 Windows 系统中，最初其重发超时的默认值一般设置为6秒（重发时间必须是0.5秒的倍数）左右。数据被重发之后若还是收不到确认应答，则进行再次发送。此时，等待确认应答的时间将会以2倍、4倍的指数函数延长。
此外，数据也不会被无限、反复地重发。达到一定重发次数之后，如果仍没有任何确认应答返回，就会判断为网络或对端主机发生了异常，强制关闭连接，并且通知应用通信异常强行终止。

四、TCP协议的缺陷

TCP的缺陷要从三次握手开始讲起，首先客户端向服务端发送SYN同步请求，服务端收到之后向客户端响应，正常来说，客户端响应之后就建立了TCP连接，但是如果客户端并没有响应呢？服务端会进行ACK重试，重试超过一定次数才会确认连接失效。假如此时有大量的客户端向服务端发送请求而不响应，那就会造成服务端不堪重负而宕掉。著名的DDoS攻击（SYN flood）就是利用了TCP协议的这个缺陷。

DDOS又称为分布式拒绝服务，全称是Distributed Denial of Service。DDOS本是利用合理的请求造成服务器资源过载，导致服务不可用。常见的DDOS攻击有SYN flood（SYN flood）、UDP flood、ICMP、flood等，其中SYN flood是一种最为经典的DDOS攻击。SYN flood如此猖獗是因为它利用了TCP协议设计中的缺陷，而TCP/IP协议是整个互联网的基础，牵一发而动全身，如今想要修复这样的缺陷几乎成为不可能的事情。

SYN flood攻击原理：