复习TCP协议——看这篇就够了

本篇文章有点长，建议收藏之后有空慢慢看喔！

TCP报文段结构

如果对TCP报文有点忘了的话，可以去我的另外一篇博客去复习喔！
传送门: 趣谈TCP三次握手.

TCP三次握手：建立连接

1.客户TCP开始时是处于CLOSED状态的。当客户端给服务器端发送SYN报文，序列号seq，客户端申请建立连接，这时处于SYN_SENT状态。
SYN = 1, seq = client_isn。

2.服务器端收到SYN报文后，给客户端发送ACK报文进行应答（允许连接），同时把客户端的 seq + 1 作为 ack，服务器端确认建立连接。此时处于 SYN_REVD状态。
SYN = 1,ACK = 1, seq = sever_isn, ack = client_isn + 1.

3.客户端收到服务器的SYNACK报文段(允许连接报文)后，客户端也发送一个ACK报文，同时SYN置0。此时处于 ESTABLISED状态，服务器收到ACK报文后也处于ESTABLISED状态，双向连接建立完成。客户端确认建立连接。
SYN = 0,ACK = 1, seq = client_isn + 1, ack = sever_isn + 1.

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开
始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关
闭连接之前，TCP 连接都将被一直保持下去。

相关问题：

1.握手过程中可以携带数据吗？

第三次握手过程中是可以携带数据的，因为此时处于ESTABLISED状态

2.初始序列号ISN是固定的吗？

为了避免某些安全性攻击，TCP的ISN是随机的。

TCP的三次握手过程？为什么会采用三次握手，若采用二次握手可以吗？

答:建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
（3）采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况。
–摘自牛客网

TCP四次挥手：断开连接

看不太懂，有点模糊化的小伙伴，可以点下面的传送门喔！
传送门: 趣谈TCP四次挥手：断开连接.

1.客户端发送FIN报文，序列号seq，客户端断开连接。此时处于FIN_WAIT1状态。
FIN = 1, seq = sever_isn

2.服务器端收到后发送ACK报文，序列号 seq ，同时把客户端的 seq + 1 作为 ack，服务器端确认客户端断开连接。客户端此时收到ACK报文后，处于FIN_WAIT2状态。
ACK = 1, seq = client_isn, ack = client_isn + 1

3.服务器发送FIN报文，服务器端断开连接。此时服务器处于 LAST_ACK状态。
FIN = 1，ACK = 1, seq = sever_isn, ack = client_isn + 1

4.客户端发送回一个ACK报文，客户端确认服务器端断开连接。此时服务器端处于 TIME_WAIT状态。
ACK = 1, seq = client_isn + 1, ack = sever_isn + 1

TIME_WAIT状态：确保服务器已经收到ACK报文。假若客户端发送回的ACK报文丢失，该状态会让客户端重新发送ACK报文。该状态时长是：2MSL（最大报文段生存时间）

相关问题：

为什么需要四次挥手断开TCP连接？

因为TCP是全双工的通信机制（全双工通信信道：双方都可以同时发送和接收），每个方向必须单独进行关闭，并且客户和服务器任何一个都可以选择关闭该TCP连接。

流量控制

TCP通过让发送方维护一个接受窗口rwnd（也叫滑动窗口）的变量来提供流量控制。接收窗口用于给发送方一个指示———该接收方还有多少可以用的缓存空间；但是因为TCP是全双工通信，所在在TCP连接的发送方都各自维护一个接收窗口；而且发送方在发送一个报文段后，会
TCP规定：当主机B的接收窗口为0时，主机A会继续发送只有一个字节数据的报文段。这些报文段将会被接收方确认。最终缓存将开始清空，并且确认报文段里将包含一个非0的rwnd值。

拥塞控制

慢启动

在慢启动状态，cwnd（拥塞窗口）的值以1个MSS开始并且每当传输的报文端首次被确认就增加一个MSS。

TCP向网络发送第一个报文段并且等待一个确认。当该确认到达时，TCP发送方将拥塞窗口增加一个MSS，并发送出两个最大长度的报文段。这两个报文段被确认，则发送方队对每个确认报文段将拥塞窗口增加一个MSS，使得拥塞窗口变为4个MSS，并且这样下去。这一过程每过一个RTT，发送速率就会翻倍。
发送速率起始慢，但在慢启动阶段以指数增长。——《计算机网络：自顶向下》

慢启动结束：

• 存在一个由超时指示的丢包事件(即拥塞)，TCP发送方将cwnd设置为1并且重新开始慢启动过程。

• 当检测到拥塞时，将 ssthresh （“慢启动阈值”）设置为 cwnd / 2，当 cwnd 到达或超过 ssthresh的值时，TCP结束慢启动并且转移到拥塞避免模式。
  检测到拥塞时cwnd >= ssthresh = cwnd / 2。

• 如果检测到3个冗余ACK，这时TCP执行一种快速重传并且进入快速恢复状态。
  冗余ACK: 就是再次确认某个报文段的ACK，而发送发现钱已经收到对该报文段的确认。

快速重传：如果主机S收到了 D1，D2，D4，D5的报文，却始终没有收到 D3的报文段，那么主机S就会连续给主机C发送 D3的ACK确认报文，告诉主机C D3报文可能丢失了，当主机C连续收到 D2的三次ACK，并且 D3还在计时范围也就是还没超时，那么主机S就会重新发送 D3。

拥塞避免

拥塞避免：一旦进入拥塞避免状态，cwnd的值大约时上次遇到拥塞时的值的一半，并且当收到3个冗余的ACK，将 ssthresh的值记录为 cwnd的值的一半。

快速恢复

快速恢复：当事件发送后，会把阈值设置为cwnd的一半，并且把cwnd设置为阈值，之后性能就会呈线性增长。这个版本也称为 TCP Reno。但是不具备这个功能的称之为 TCP Tahoe。

可靠数据传输(reliable data transfer service)

TCP的可靠数据传输服务确保一个进程从其接收缓存中读出的数据流是无损换、无间隔、非冗余和按序的数据流；即该字节流与连接的另一方端系统发送出的字节流是完全相同。——摘自《计算机网络:自顶向下》

确认重传机制

在数据分组种添加一个新字段，让发送方对其发送的数据分组进行编号，即：将发送数据分组的序号放在该字段。
这样，接收方就只需要检查序号就可以确定收到的分组是否进行过一次重传。

回退N步(GBN)协议

在回退N步(GBN)协议中，允许发送方发送多个分组(当有多个分组可以用时)而不需要等待确认，然是它也受限于流水线种未确认的分组数不能超过某个最大允许数N。
N常被称为窗口长度(window size)，GBN协议也常被称为滑动窗口协议(sliding-window protocol)。

• 接收方：如果数据分组是按顺序到达的，则选择接收，否则接收方发送ACK报文进行累积确认，表明接收方已正确接收到序号为n的以前且包括n在内的所有分组。

超时事件：如果收到一个ACK，但是仍有已发送但是未被确认的分组，则定时器被重新启动。如果没有已发送但未被确认的分组，则定时器被终止。

• 发送方：收到基序号(base)的ACK报文，代表基序号之前的数据分组已确认收到。

选择重传(SR)

选择重传(SR)协议通过让发送方仅仅重传那些它怀疑在接收方出错(即丢失或者受损)的分组而避免了不必要的重传。
SR接收方将确认一个正确接收的分组而不管其是否按序。失序的分组将被缓存知道所有丢失分组(即序号更小的分组)皆被收到为止，这时才将一批分组按序交给上层。

• 接收方：接收方会缓存没有按序到达的报文，等到报文按序后，再发送ACK确认报文。确认报文都已按序到达。
• 发送方：发送方会为每个未发送的报文设置一个定时器，哪个超时后就发送哪个报文。定时器用来防止丢失分组。

停等协议(stop-and-wait)

当发送方处于等待ACK或者NAK的状态时，发送方将不会发送新数据，除非发送方确认接收方已正确接收到当前分组。

流水线可靠数据传输协议

允许发送方发送多个分组而无需等待确认。
因为许多从发送方向接收方输送的分组可以被看成是填充到一条流水线中，故这种技术也被称为流水线(pepelining)。

可靠数据传输机制及其用途的总结

机制	用途和说明
检验和	用于检测再一个传输分组中的比特错误
定时器	用于超时/重传一个分组，可能因为该分组(或其ACK)再信道中丢失了。由于当一个分组延时但是未丢失(过早超时)，或当一个分组已被接收方收到但从接收方到发送方的ACK丢失时，可能产生超时事件，所以接收方可能会收到一个分组的多个冗余副本。
序号	用于从发送方流向接收方的数据分组按顺序编号。所接收分组的序号间的空隙可使得接收方检测出丢失的分组。具有相同序号的分组可使接收方检测出一个分组的冗余副本
确认	接收方用于告诉发送方一个分组或者一组分组已经被正确的接收到了。确认报文通常携带着被确认的分组或者多个分组的序号。确认可以是逐个的或者累积的，这取决于协议
否定确认	接收方用于告诉发送方某个分组未被正确的接收。否定确认报文通常携带着未被正确接收的分组的序号
窗口和流水线	发送方也许被限制仅发送那些序号落在一个指定范围内的分组。通过允许一次发送多个分组但是未被确认，发送方的利用率可在停等操作模式的基础上得到增加。我们很快将会看到，窗口长度可根据接收方接收和缓存报文的能力、网络中的拥塞程度或两者情况来进行设置

TCP和UDP的区别？

TCP提供面向连接的、可靠的数据流传输，而UDP提供的是非面向连接的、不可靠的数据流传输。
TCP传输单位称为TCP报文段，UDP传输单位称为用户数据报。
TCP注重数据安全性，UDP数据传输快，因为不需要连接等待，少了许多操作，但是其安全性却一般。
TCP对应的协议和UDP对应的协议
TCP对应的协议：
（1） FTP：定义了文件传输协议，使用21端口。
（2） Telnet：一种用于远程登陆的端口，使用23端口，用户可以以自己的身份远程连接到计算机上，可提供基于DOS模式下的通信服务。
（3） SMTP：邮件传送协议，用于发送邮件。服务器开放的是25号端口。
（4） POP3：它是和SMTP对应，POP3用于接收邮件。POP3协议所用的是110端口。
（5）HTTP：是从Web服务器传输超文本到本地浏览器的传送协议。
UDP对应的协议：
（1） DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
（2） SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
（3） TFTP(Trivial File Transfer Protocal)，简单文件传输协议，该协议在熟知端口69上使用UDP服务。
摘自–牛客网

如果已经建立了连接，但是客户端突然出现故障了怎么办？

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