目录
一、简介
在世界上各地，各种各样的电脑运行着各自不同的操作系统为大家服务，这些电脑在表达同一种信息的时候所使用的方法是千差万别。就好像圣经中上帝打乱了各地人的口音，让他们无法合作一样。计算机使用者意识到，计算机只是单兵作战并不会发挥太大的作用。只有把它们联合起来，电脑才会发挥出它最大的潜力。于是人们就想方设法的用电线把电脑连接到了一起。
但是简单的连到一起是远远不够的，就好像语言不同的两个人互相见了面，完全不能交流信息。因而他们需要定义一些共通的东西来进行交流，TCP/IP就是为此而生。TCP/IP不是一个协议，而是一个协议族的统称。里面包括了IP协议，IMCP协议，TCP协议，以及我们更加熟悉的http、ftp、pop3协议等等。电脑有了这些，就好像学会了外语一样，就可以和其他的计算机终端做自由的交流了。
TCP(Transmission Control Protocol传输控制协议)是一种面向连接的、可靠地、基于字节流的传输层通信协议。UDP协议是该层另一个重要协议。
应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，然后TCP把数据流分区成适当长度的报文段（最大报文长度MSS[Maximum Segment Size]受数据链路层的MTU限制），之后TCP把结果包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。TCP为了保证不丢包，给每个包发送一个序号，同时该序号保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认（ACK）。如果发送端实体在合理往返时延RTT内未收到确认，难么对应的数据包就被假设为已丢失将会被重传。
1、数据正确与合法性上，TCP用一个校验和函数来校验数据是否有错。在发送和接收时都要计算校验和。同时可以使用MD5对数据加密。
2、在保证可靠性上，采用超时重传和捎带确认机制。
3、在流量控制上，采用滑动窗口协议，协议规定，对于窗口内未经确认的分组需要重传。
4、在拥塞控制上，采用TCP拥塞控制算法(AIMD算法)。该算法主要包括三个部分：a、加性增、乘性减。b、慢启动。c、对超时事件作出反应。
二、TCP首部格式
TCP数据被封装在IP数据报中：
TCP报文段格式（20字节的首部+数据）：
1、16位源端口号和16位目的端口号：用于寻找发送端和接收端的应用进程，加上IP首部的源端IP和目的端IP地址，唯一的确认了一个TCP连接。
2、32位序号(seq)：标识发送的数据字节流，标识在这个报文段中的第一个数据字节，
3、32位确认序号(ack)：标志位ACK为1时有效，上次收到的数据字节序号+1（如接收到的为1024~2048，则返回2049）。
4、4位首部长度：首部中32bit字的数目(以32bit为单位)。TCP最多有60字节的长度，出去任选字段，正常20字节。
5、6bits：URG紧急指针；ACK确认序号有效；PSH接收方应尽快将此报文段交给应用层；RST重建连接；SYN同步序号，用来发起一个新连接；FIN发送端完成发送任务。
6、16位窗口大小：TCP流量控制，字节数，起始于确认序列号指明的值，接收端期望接收到的字节，最大65535字节。
7、16位校验和：包括计算TCP首部和综合数据的二进制反码和校验和。
8、16位紧急指针：URG为1时有效，正向的偏移量，加上序号字段值表示最后一个字节序号。
9、可选字段：如MSS。
三、TCP连接建立、数据传输与连接终止
3.1、连接建立——三次握手
第一次握手：客户端发送syn包(seq=x)到服务器。并进入SYN_SEND状态，等待服务器确认。
第二次握手：服务器收到syn包，必须发回对客户发来syn包的确认(ACK=x+1)，同时自己也发送一个SYN包(seq=y),即SYN+ACK包，此时服务器进入SYN_RECV状态。
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ACK=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
握手过程中传送的包里不包含数据，三次握手完毕之后，客户端与服务器才正式传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP连接都将一直被保持下去。
3.2、传输数据
1、超时重传：用来保证TCP传输的可靠性。每次发送数据包时，发送的数据报都有seq号，接收端收到数据后，会回复ack进行确认，表示某一seq号数据已经收到。发送方在发送了某个seq包后，等待一段时间，如果没有收到对应的ack回复，就认为报文丢失，会重传这个包。
2、快速重传：接收方发现数据包丢失。就会发送ack报文告诉发送端重传丢失的报文。如果发送端连续收到标号相同的ack包，则会触发客户端的快速重传。比较超时重传和快速重传，可以发现超时重传是发送端在“傻等”超时，然后触发重传。而快速重传则是接收端主动告诉发送端数据没到，然后触发发送端重传。
3、流量控制：主要说TCP滑动窗口流量控制。TCP头里有一个字段叫window，也叫Advertised-Window，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据接收方的“接收能力”来发送数据，以免导致接收方“处理不过来”。滑动窗口是提高TCP传输效率的一种机制。
4、拥塞控制：流量控制只关注发送端和接收端自身情况，没有考虑整个网络通信状况。拥塞控制则是基于整个网络考虑的。如果某一时刻网络上的延时突然增加，那么TCP对这个状况做出的应对只有重传数据，但是，重传会导致网络上负担更重，造成更大延迟以及更多的丢包。于是这个情况会进入恶性循环并不断放大。试想一下，如果一个网络内有成千上万的TCP连接都这么干，会形成“网络风暴”。TCP这个协议就会拖垮整个网络。为此TCP引入了拥塞控制策略。算法主要包括：慢启动，拥塞避免，拥塞发生，快速恢复。
3.3、连接终止——四次挥手
第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(当然，在FIN包之前发送出去的数据，如果还没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但此时主动关闭方还可以接收数据。
第二次挥手：被动关闭方收到FIN包，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。
1、客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2、服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3、客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4、服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5、客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6、服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
【问题&解析】
Q1:【为什么连接是三次握手，断开是四次挥手？】
A1:首先TCP是全双工的，假设A和B是通信双方。握手实际上就是通信，发送一次信息就进行一次握手：
第一次握手：A给B打电话说：“你可以听到我说话吗？”。
第二次握手：B收到了A的信息，然后对A说：“我可以听得到你说话啊，你能听到我说话吗？”。
第三次握手：A收到了B的信息，然后说：“我能听到你的声音，那我们愉快的交流吧！”
在三次握手之后，A和B都能确定这么一件事：我说的话，你能听到；你说的话我也能听到，这样就可以正常通信了。
需要注意的是：HTTP基于TCP协议，所以每次都是客户端发送请求，服务器响应，但是TCP还可以给其它应用层提供服务，即可能在A、B建立连接后，谁都可以先开始通信。
如果两次：假定A给B发送一个连接请求，B收到了这个分组，并发送了确认应答。按照两次握手协定，B认为连接已经成功建立了，可以开始发送数据分组，可是在B的应答分组在传输中被丢失情况下，A将不知道B是否已准备好，不知道B建立什么样的序号，甚至怀疑B是否有收到自己发出的连接请求分组，这种情况下A认为连接还未建立成功，将忽视B发来的任何数据分组，只等待连接确认应答分组。AB在发出的分组超时后重复发送同样的分组，这样会形成死锁。
如果四次：那么久造成了浪费，因为在三次结束后，就已经可以保证A可以给B发信息，A可以收到B的信息；B可以给A发信息，B可以收到A的信息。建立连接握手三次最优。
当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步挥手。
Q2:【三次握手在正常情况都进行了什么操作？】
A2:
第一次握手：客户端发送一个TCP的SYN位置1的包指明客户打算连接的服务器端口，以及初始序号X，保存在包头的序列号字段里。
第二次握手：服务器发回确认包应答ACK。即SYN位和ACK位均置1，同时将确认序号(Acknowlegement Number)设置为客户的ISN加1，即X=1。
第三次握手：客户端再次发送确认包ACK，SYN标志位为0，ACK标志位是1，并且把服务器发来的ACK序号字段+1，放在确认序号字段中发送给对方，并且在数据段放写入的X+1。
SYN就是询问：你能听到吗？ACK就是回复：我能听到！
Q3：【为什么TIME_WAIT状态需要经过2MSL（最大报文生存时间）才能回到CLOSE状态？】
A3：虽然按道理，四个报文都发送完毕，就可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，可能最后一个ACK丢失。所以TIME_WATI状态就是用来重发可能丢失的ACK报文。在客户端发送出最后ACK恢复，但该ACK可能丢失。服务端如果没有收到ACK，将不断重复发送FIN片段。所以客户端不能立即关闭，必须确认服务端收到了该ACK。客户端会在发送出ACK后进入到TIME_WAIT状态。客户端会设置一个计时器，等待2MSL时间。如果该时间内再次收到FIN，那么客户端会重发ACK并再次等待2MSL。MSL(Maximun Segment Lifetime)指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需最大时间。如果直到2MSL，客户端都没收到再次收到FIN，那么客户端推断ACK已经被成功接收，则结束TCP连接。
Q4：【如果已经建立了连接，但是客户端突然出现故障怎么办？】
A4：TCP还有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常设置为2小时，若两小时还没有收到客户端任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没有反应，服务器就认为客户端出了故障，接着关闭连接。
Q5：【TCP拥塞控制是什么？】
A5：
拥塞控制主要是四个算法：
1、慢启动：意思是刚加入网络的连接，一点点提速，不要一上来就把网络占满。
建立连接时初始化cwnd=1，表明可以传1个MSS大小的数据。每当收到一个ACK，cwnd++，呈线性上升。
每当过了一个RTT(往返时间round trip time)，cwnd=cwnd*2，呈指数上升。
阈值ssthresh(slow start threshold)是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”。
2、拥塞避免：当拥塞窗口cwnd达到一个阈值时，窗口大小不再呈指数上升，改为线性上升，避免增长过快导致网络拥塞。
每当收到一个ACK，cwnd=cwnd+1/cwnd。
每当过了一个RTT，cwnd = cwnd + 1。
拥塞发生：当发生丢包进行数据重传时，表示网络已经拥塞。处理方法：等到RTO超时，重传数据包。Ssthresh=cwnd/2，cwnd置1.
3、快重传：在收到3个冗余ACK时就开始重传，而不用等到RTO超时：ssthresh=cwnd=cwnd/2。
4、快速恢复：至少收到了3个冗余ACK，说明网络不那么糟糕，可以快速恢复。
cwnd = ssthresh + 3*MSS(3的意思是确认有3个数据包被收到了)
重传冗余ACK指定的数据包。如果有再收到冗余ACK，那么cwnd=cwnd+1。如果收到了新的ACK，那么，cwnd=ssthresh，然后进入拥塞避免算法。
【补充知识】
1、SYN攻击
在三次握手过程中，服务端发送SYN-ACK后，收到客户端的ACK前的TCP连接称为半连接，此时服务端处理SYN_RCVD状态，当收到ACK后，服务端转入ESTABLISHED状态。SYN攻击就是客户端在短时间内伪造大量不存在的IP地址，并向服务端不断发送SYN包，服务端回复确认包，并等待客户端的确认，由于源地址是不存在的，因此服务端需要不断重发直至超时。这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击是一种典型的DDOS攻击，检测SYN攻击的方式也很简单，即当服务端上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，可以使用如下命令：
#netstat -nap | grep SYN_RECV
2、TCP是面向连接的、端到端的、可靠地面向字节流的服务，在一个TCP连接中，仅有两方彼此通信，所以TCP不能在广播和多播上得到应用。
3、TCP的可靠性实现
a.应用数据被分割成TCP认为最适合发送的数据块，这和UDP完全不同，应用程序产生的数据长度将保持不变。由TCP传给IP层的信息单位称为报文段或段segment。
b.当TCP发出一个段后，启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当收到另一端的数据，将发送一个确认。TCP有延迟确认功能，在此功能没有打开，则是立即确认。如果功能打开，则由定时器触发确认时间点。
c.TCP将保持首部和数据的校验和。这是一个端到端的校验和，目的是检测数据在传输过程中的任何变化。如果收到段的校验和有差错，TCP将丢弃这个报文段和不发送收到此报文段的确认ACK（希望对方超时重发）。
d.既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确顺序交给应用层。
e.既然IP数据报会发生重复，TCP的接收端必须丢弃重复数据。
f.TCP还提供流量控制。TCP连接的每一方都有固定大小缓冲空间。TCP的接收端只允许另一端发送接收方缓冲区所能容纳的数据。防止较快主机致使较慢主机缓冲区溢出。
例如：两个应用程序通过TCP连接交换8bit字节构成的字节流。TCP不在字节流中插入记录标识符。我们将这称为字节流服务(byte stream service)。如果一方的应用先传10字节，又传20字节，再传50字节，连接的另一方将无法了解发送方每次发送了多少字节。只要自己接收缓存没有塞满，TCP接收方将有多少接收多少。一段将字节流放到TCP连接上，同样的字节流将出现在TCP连接的另一端。
另外，TCP对字节流的内容不作任何解释。TCP不知道传输的数据字节流是二进制数据，还是ASCII字符或其他类型数据。对字节流的解释由TCP连接双方的应用层解释。
4、超时重传策略
TCP协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重传定时器，如果在重传超时前收到确认就关闭该重传，如果重传超时前没有收到确认。则重传该数据段。
选择重发时间的过程中，TCP必须有自适应性，需要根据互联网当时状况，给出合适重发时间。这种重传策略关键是对定时器初始值的设定。采用较多算法是jacobson于1988年提出的一种不断调整超时时间间隔的动态算法。原理：对每条TCP连接保持一个变量RTT（往返时间：Round Trip Time），用于存放当前到目的端往返所需时间的估计值。当发送一个数据段时，同时启动连接的定时器，如果在定时器超时前确认到达，则记录所需要的时间M，并修正RTT的值，如果定时器超时前没有收到确认，则将RTT值增加1倍。通过测量一系列RTT值，TCP协议可以综合诸多算法估算出数据包重发前需要等待的时间。
5、快速重传机制
超时重传带来的问题：
1、当一个报文段丢失时，会等待一定的超时周期然后才重传分组，增加了端到端时延。
2、当一个报文段丢失时，在其等待超时的过程中，可能会出现这种情况：其后的报文段已经被接收端接收但却迟迟得不到确认，发送端会认为也丢失了，从而引起不必要的重传，既浪费资源也浪费时间。
但好在TCP采用的是累计确认机制，即当接收端收到比期望序号大的报文段时，便会重复发送最近一次确认的报文段的确认信号，称为冗余ACK(duplicate ACK)。
如图，报文段1成功接收并被确认ACK2，接收端的期望序号为2，当报文段2丢失，报文段3失序到来，与接收端的期望不匹配，接收端重复发送冗余ACK2。这样在超时重传定时器溢出之前，接收到连续的三个冗余ACK(其实是收到4个同样的ACK，第一个是正常的，后三个才是冗余的)，发送端便知晓哪个报文段在传输过程中丢失了，于是重发该报文段，不需要等待超时重传定时器溢出，大大提高了效率，这边是快速重传机制。
为什么是三次冗余ACK呢？
首先，即使发送端是按序发送，由于TCP包是封装在IP包内，IP包传输时乱序，意味着TCP包到达接收端也是乱序的，乱序的话也会造成接收端发送冗余ACK。那么发送冗余ACK是乱序造成还是包丢失造成的呢？
假定通信双方如下：
A为发送端，B为接收端。A的待发报文段序号为N-1，N，N+1, N+2。假设报文段N-1成功到达。
从以上罗列情况看出，没丢失情况下，有40%可能出现3次冗余·。在乱序情况下必定是2次冗余ACK。在丢失情况下必定出现3次冗余ACK。正是基于这样的概率，选定3次冗余ACK作为阈值也算是合理的。在实际抓包中，大多数快速重传都会在大于3次冗余ACK后发生。
快速重传应用实例：图一是在某报文段的超时重传定时器溢出前重传丢失报文段，第二幅图是对应的接收端缓存队列的窗口移动示意。
6、拥塞控制策略
产生原因
产生的原因：对资源需求 > 可用资源。
注意：单纯的增加网络资源无法解决问题。如把节点存储空间扩大，更换更高速率链路，提高节点处理运算速度，不仅不能解决问题，还可能使得网络性能更坏。
原因：网络拥塞是许多因素引起的，单纯的解决一个可能会使上述情况得到一些缓解，但是会把拥塞转移到其他地方。
扩大节点存储空间——由于输出链路容量和处理机速度并未提高，增大排队等待时间，超时重传，浪费资源。
更换更高速率链路——可能会缓解，有可能造成各部分不匹配。
拥塞控制作用
注意：
1、流量控制与拥塞控制区别。
2、拥塞控制是防止过多的数据注入到网络，可以使网络中路由器或链路不致过载，是一个全局性过程。
3、流量控制是点对点通信量的控制，是一个端到端的问题，主要是抑制发送端发送数据的速率，以便接收端来得及接收。
拥塞的标志
1、重传计时器超时。
2、接收到三个重复确认。
拥塞控制的机制
慢开始
1、慢开始不是指cwnd的增长速度慢(指数增长)，而是指TCP开始发送设置cwnd=1。
2、思路：不要一开始就发送大量数据，先探测一下网络拥塞程度，也就是说由小到大逐渐增加拥塞窗口大小。这里用报文段个数的拥塞窗口大小举例说明慢开始算法，实时拥塞窗口大小是以字节为单位的。
3、为了防止cwnd增长过大引起网络拥塞，设置一个慢开始门限(ssthresh状态变量)
当cwnd < ssthresh，使用慢开始算法。
当cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法。
当cwnd > ssthresh，使用拥塞避免算法。
拥塞避免(线性规律增长)
1、拥塞避免并非完全能够避免拥塞，是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。
2、思路：让拥塞窗口cwnd缓慢增长，即每经过一个往返时间RTT就把发送方拥塞窗口+1.
无论是在慢开始阶段还是拥塞避免阶段，只要发送方判断出网络出现拥塞（根据是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，均当做拥塞处理）。就把慢开始门限设置为出现拥塞时的发送窗口的一半大小。然后把拥塞窗口设置为1，执行慢开始算法。
加法增大与乘法减小
乘法减小：无论是慢开始阶段还是拥塞避免，只要出现了网络拥塞(超时)，就把慢开始门限值ssthresh减半，拥塞窗口置1。
加法增大：执行拥塞避免算法后，拥塞窗口线性缓慢增大，防止网络过早出现拥塞。
快重传
1、快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)，而不要等到自己发送数据时捎带确认。快传算法规定，发送方只要一连收到3个重复确认就应当立即重传对方尚未收到的报文段，而不必等待设置的重传计时器时间到期。
2、由于不需要等待设置的重传计时器到期，能尽早重传未确认的报文段，能提高整个网络吞吐量。
快恢复(与快重传配合)
1、采用快恢复算法时，慢开始只在TCP连接建立时和网络出现超时时候才使用。
2、当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。
3、考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。
注意：
发送方窗口的上限值=Min(接收窗口rwnd，拥塞窗口cwnd)
rwnd > cwnd 接收方的能力限制发送方窗口最大值。
rwnd < cwnd 网络的拥塞限制发送方窗口最大值。
名词解释：
RTT(Round Trip Time)：一个连接的往返时间，即数据发送时刻到接收到确认的时刻的差值；
RTO(Retransmission Time Out)：重传超时时间，即从数据发送时刻算起，超过这个时间便执行重传。
RTT和RTO 的关系是：由于网络波动的不确定性，每个RTT都是动态变化的，所以RTO也应随着RTT动态变化。
【扩展资料】
1、IP协议
扫一扫
1175
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
