一文解析TCP知识体系

TCP（传输层协议）

特点：
1. TCP是面向连接的。应用程序在使用TCP之前，必须先建立连接。在数据传输结束后，会马上释放已经建立的连接。
2. TCP提供可靠的交付服务。通过TCP传输的数据，保证完整性、不丢失、不重复。
3. TCP连接是点对点的。每一条TCP连接只能有两个端点，这个端点叫套接字（socket），即是两个IP。
4. TCP是面向字节流的。流，指的是流入到进程或从进程流出的字节序列。面向字节流是指：虽然应用程序和TCP的交互是一次一个数据块，但是TCP把应用层传递过的数据看成一串无结构的字节流，放置在发送缓冲区中，如果数据太大，则需要分片后再进行发送。发送的数据大小跟应用层过来的报文没有任何关系。

如何做到可靠传输？
停止等待ARQ协议，停止等待，就每发送一个分组数据后就停止发送，等待对方确认。在收到确认之后在发下一个分组数据。
超时重发,如图，A向B发送数据，但过了一段时间后,A没有收到B得确认信息，再次发送信息，而后B向A发送确认信息，但这里要注意，若第一次请求发送得请求因延迟再次返回后，A收到后什么也不做。

流量控制：
如果发送方的发送速度太快，接受方来不及接收，就可能造成数据丢失。这里说的流量控制，就是让发送方不要发得太快，让接受方能够来得及接收。

原理
1. 通过确认报文中的窗口字段控制发送方的窗口大小，控制发送方的发送速率。
2. 发送方的窗口大小不能超过接收方给出的窗口大小。
3. 若接收方给出的窗口大小为0，发送方就会停止发送数据。

拥塞控制
作用：防止过多的数据在网络中传输，在网络带宽有限的情况下，造成网络链路过载。
控制拥塞是一个全局性的过程，涉及到所有的主机、路由器、降低能影响网络传输的因素，它与流量控制不同，流量控制是点对点的控制。
控制拥塞的算法有四种：慢开始、拥塞避免、快重传、快恢复

慢开始
顾名思义，就是开始的时候慢慢传，当主机发送数据时，在不知道网络负荷的情况下，如果马上进行数据大量传输，就可能造成网络拥塞，可以进行试探，慢慢增加发送窗口。
拥塞避免
拥塞避免则是指，窗口拥塞到一定的阈值之后，就转换成线性增长，缓慢增长。
快重传
这种情况适用于个别报文在传输过程中丢失，但是实际上网络并未出现拥塞，如果发送方迟迟收不到确认，就会发送了拥塞，并开启慢启动，把cwnd设置为1。而快重传则是用在当多个分组传输时，中间某个分组数据丢失，接收方会连续方式重复的三个确认，这样接收方就知道并不是网络拥塞。
快恢复
这种适用于发送方只知道丢失了某个报文段，于是不启动慢开始，而是执行恢复算法。该算法先乘法减小算法，把ssthresh缩减为拥塞峰值的一半，并把cwnd设置为新的ssthresh值，而后把cwnd值设置为新的ssthresh值。然后开始执行拥塞避免算法（加法增大），使cwnd缓慢地线性增大，但cwnd值不会恢复到初始值。

TCP三次握手
如图，
CLOSED：处于关闭状态
LISTEN：服务器处于监听状态，等待客户端连接
SYN-SENT：表示客户端已发送SYN报文，等待服务器的第2次握手
SYN-RCVD：表示服务器接收到了SYN报文。当继续收到客户端的ACK报文后，它会进入到ESTABLISHED状态
ESTABLISHED：表示连接已建立
再说说各个标志位

标志位	释义
SYN	同步序列号，用于发起一个新连接
ACK	确认序列号，确认序列有效
FIN	终止序列号，释放应该连接
RST	重置连接

第一次握手，客户端主动发起连接，发送SYN报文，并进入SYN_SENT状态，等待服务端的确认。
第二次握手，服务器收到SYN报文，需要给客户端发送ACK确认报文，同时服务器也要向客户端发送一个SYN报文，即是发送ACK+SYN报文，此时服务器进入SYN-RCVD状态。
第三次握手，客户端收到服务端的ACK+SYN报文，向服务器发送确认包客户端进入ESTABLISHED，服务端收到客户端的ACK报文也会进入ESTABLISHED状态.
为什么两次握手不行

1.确认双方的收包、发包能力，需要确认客户端、服务器的接收、发送包的能力都没问题。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。所以，只有三次握手才能确认双方的接收与发送能力是否正常。

2.两次握手浪费资源，假设有这么一种情况。客户端第一次向服务端请求建立连接时，因为网络超时的原因触发重传，于是客户端第二次向服务端请求建立连接。这一次建立连接、传送数据、断开连接都很顺利。连接断开后许久，之前在某个网络节点滞留的第一次请求终于到达了服务端，本来这是一个已经失效的请求，但是服务端会认为这是客户端新建立的请求，于是向客户端发出确认。如果只需要两次握手，服务端将进入连接状态。但是客户端本质上并没有想建立连接，所以在收到服务端的确认之后，它什么也不会做。而服务端误认为已经进入了连接状态，还在一直等待客户端发送数据，白白浪费了资源。如果采用三次握手，服务端在给出客户端的确认后，发现没有继续收到客户端的确认，就知道客户端并没有想建立连接。
3.序列号可靠同步，如果是两次握手，服务端无法确定客户端是否已经接收到了自己发送的初始序列号，如果第二次握手报文丢失，那么客户端就无法知道服务端的初始序列号，那 TCP 的可靠性就无从谈起。

第三次握手失败了怎么办？
第二次握手之后，服务端的状态为SYN-RCVD，若等不到客户端的ACK，服务端会重新发送SYN+ACK包。如果服务端多次重发SYN+ACK都等不到客户端的ACK，就会发送RST包，强制关闭连接。

前两次握手能否发送数据？
不能，凡是携带SYN的报文，均不能发携带数据，若再第一、二次握手携带数据，如果有人要恶意攻击服务器，疯狂重复发送SYN报文，并在报文中加入大量数据，这会让服务器花费大量的内存来缓存这些报文，造成服务器被攻击。但是这里要注意，第三次握手时，客户端已经可以正常收发，所以携带数据是合理的。

什么是SYN攻击
在三次握手过程中，服务器发送 SYN-ACK 之后，收到客户端的 ACK 之前的 TCP 连接称为半连接(half-open connect)。此时服务器处于 SYN_RCVD 状态。当收到 ACK 后，服务器才能转入 ESTABLISHED 状态. SYN 攻击指的是，攻击客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送SYN包，服务器回复确认包，并等待客户的确认。由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，导致目标系统运行缓慢，严重者会引起网络堵塞甚至系统瘫痪。

四次挥手
如图

1. 第一次挥手。客户端发起 FIN 包（FIN = 1）,客户端进入 FIN_WAIT_1 状态。TCP 规定，即使 FIN 包不携带数据，也要消耗一个序号。
2. 第二次挥手。服务器端收到 FIN 包，发出确认包 ACK（ack = u + 1），并带上自己的序号 seq=v，服务器端进入了 CLOSE_WAIT 状态。这个时候客户端已经没有数据要发送了，不过服务器端有数据发送的话，客户端依然需要接收。客户端接收到服务器端发送的 ACK 后，进入了 FIN_WAIT_2 状态。
3. 第三次挥手。服务器端数据发送完毕后，向客户端发送 FIN 包（seq=w ack=u+1），半连接状态下服务器可能又发送了一些数据，假设发送 seq 为 w。服务器此时进入了 LAST_ACK 状态。
4. 第四次挥手。客户端收到服务器的 FIN 包后，发出确认包（ACK=1，ack=w+1），此时客户端就进入了 TIME_WAIT 状态。注意此时 TCP 连接还没有释放，必须经过 2*MSL 后，才进入 CLOSED 状态。而服务器端收到客户端的确认包 ACK 后就进入了 CLOSED 状态，可以看出服务器端结束 TCP 连接的时间要比客户端早一些。

为什么TCP建立连接是三次握手，断开连接是四次挥手？
在建立连接的过程中，第二次握手的时候是将SYN+ACK 合并到一个包里，所以减少了一次请求。而因为TCP是全双工通信，之所以断开连接不能是三次挥手，是因为客户端发送完FIN后，服务器仍可能需要发送数据，不能立即关闭服务端与客户端的数据通道，即不能将服务器的FIN与客户端的ACK合并发送，只能先发送确认ACK,待服务器无需发送数据后，再发送FIN包。

为什么TIME_WAIT需要2MSL

首先MSL指的是报文网络中最大生存时间

在服务端发送FIN包后，有可能接收不到客户端的ACK确认包，这时候就需要重发，所以留出来的这2MSL时间内，若客户端没有收到服务端再次发送的FIN，就可以确保服务器已经收到客户端的ACK确认报文。
在客户端发送完最后一个ACK报文后，在经过2MSL时间后，就可以让本次连接的时间内产生的所有报文全部清空，避免下次连接不会带上这种旧的报文。

结语
感谢你的耐心观看，TCP是一个比较复杂的协议,若有讲的不对的地方希望可以指出！

一文解析TCP知识体系相关推荐

一文读懂分布式架构知识体系（内含超全核心知识大图）
作者 | 晓土阿里巴巴高级工程师姊妹篇阅读推荐:<云原生时代,分布式系统设计必备知识图谱(内含22个知识点)> 导读:本文力求从分布式基础理论.架构设计模式.工程应用.部署运维.业界方 ...
一文看懂大数据生态圈完整知识体系【大数据技术及架构图解实战派】
一文看懂大数据生态圈完整知识体系徐葳随着大数据行业的发展,大数据生态圈中相关的技术也在一直迭代进步,作者有幸亲身经历了国内大数据行业从零到一的发展历程,通过本文希望能够帮助大家快速构建大数据生态圈 ...
layui 如何动态加载局部页面_从输入URL到页面加载的过程？如何由一道题完善自己的前端知识体系！
前言见解有限,如有描述不当之处,请帮忙指出,如有错误,会及时修正. 为什么要梳理这篇文章? 最近恰好被问到这方面的问题,尝试整理后发现,这道题的覆盖面可以非常广,很适合作为一道承载知识体系的题目. ...
落魄前端，整理给自己的前端知识体系复习大纲（下篇）
前言首先,感谢一些同行们对上篇的肯定. 其次,文章标题为"大纲",只是笔者,整理给自己的一个复习大纲. 也许内容并不深入,因为文章的标题与定义就是大纲,并没指望一篇文章,可以教会 ...
从输入URL到页面加载的过程？由一道题完善自己的前端知识体系！
梳理主干流程这道题上,如何回答呢?先梳理一个骨架. 知识体系中,最重要的是骨架,脉络.有了骨架后,才方便填充细节.所以,先梳理下主干流程: 从浏览器接收url到开启网络请求线程(这一部分可以展开浏览 ...
vue01-前端知识体系（狂神）
1.概述 Vue (读音 /vjuː/,类似于 view) 是一套用于构建用户界面的渐进式JavaScript框架,发布于2014年2月. 与其它大型框架不同的是,Vue 被设计为可以自底向上逐层应用 ...
一篇文章构建你的 NodeJS 知识体系(W字长文)
作者:RingChenng,原文地址:https://juejin.im/post/6844903767926636558 最近读<重学前端>,开篇就是让你拥有自己的知识体系图谱,后续学的 ...
一篇文章构建你的 NodeJS 知识体系
最近读<重学前端>,开篇就是让你拥有自己的知识体系图谱,后续学的东西补充到相应的模块,既可以加深对原有知识的理解,又可以强化记忆,很不错的学习方案. 这篇文章主要知识点来自: <No ...
架构师知识体系(5)--建立自己的知识体系吧
http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=400103116&idx=1&sn=89bc2f3644603ffc ...
2020前端知识体系（图谱）
前言随着前端的不断发展,各种框架概念层出不穷,初级希望能了解前端整个知识体系,加强对前端认知,有一定工作经验的前端工程师也希望能构建自己的知识体系,往更高的层次迈进.因此本人查阅多方资料,结合自己的 ...

一文解析TCP知识体系

一文解析TCP知识体系相关推荐

最新文章

热门文章