计算机网络-运输层协议 TCP/UDP协议（TCP与UDP对比，流量控制，拥塞控制，三次握手，四次挥手）

运输层协议：TCP/UDP协议

Java计算机网络方面常见面试题：

• 网络分层协议（TCP/IP分层协议和OSI分层协议）
• 三次握手过程，能否少一次握手
• TCP与UDP协议的区别
• 浏览器输入一个网址的过程

1. 运输层(传输层)概述

• TCP/IPx协议体系分层：应用层-传输层-网络层-数据链路层-物理层
• 网络层是描述的是机器与机器的通信，代表协议是IP协议
• 运输层是为应用层提供服务，描述的是进程与进程的通信
• 通过端口来区分不同的应用进程
  系统端口：0~1023（需要登记注册）
  登记端口：1024~49151（需要登记注册）
  客户端端口：49152~65535,客户端临时端口号。这是为什么一般建议改端口号时需要改大一点，因为太小了容易和已有的应用端口重复，占用其他应用的端口
  常见端口：FTP 21；DNS：53；HTTP：80；HTTPS：443； MySQL：3306；Tomca：8080；Redis：6379
• 运输层有两类协议：

1. TCP协议；对应的应用层协议：HTTP，FTP。TELNET，SMTP
2. UDP协议；对应上层协议：DNS，TFTP，DHCP，IP电话

2. UDP（用户数据报协议）

2.1 UDP特点

• 无连接(不需要事先建立连接)
• 尽最大努力交付（不可靠交付）
• 面向用户数据报
• N对N
• 没有拥塞控制
• 首部开销小（才8字节）
• 差错校验

2.2 UDP首部

源端口（2字节）
目的端口（2字节）
长度（2字节）：整个数据报的长度，包括首部，所有最小为8（字节）
校验和（2字节）：用来计算是否有差错，有就丢弃

2.3 差错校验

留个位置下次再来

2.4 小结

UDP是面向数据报的，用户给的什么数据就是什么数据，而且从UDP的首部也可以看出来，UDP仅提供了仅提供了差错校验功能，他的功能都没有。所以首部比较短，。传输效率高；
而且从首部也可以看出来，提供的是端口号，因为运输层是为进程间通信提供服务的。IP地址在下面的网络层IP数据报了会指定IP地址，运输层不提供IP地址

3. TCP（传输控制协议）

3.1 TCP特点

• 面向连接（先进行连接在发送(三次握手)）
• 可靠交付
• 面向字节
• 1对1
• 有流量控制和拥塞控制
• 首部开销大（最小20字节，长的有40字节）
• 差错校验

TCP与UDP的对比直接看特点就好了。

3.2 TCP报文首部

• 源端口和目的端口：各占2字节
• 序号：占4字节，表示该数据报里第一个字节的序号
• 确认号：期望收到下一个报文段的第一个数据字节的序号
• 数据偏移：TCP数据报的长度 PS：（为什么UDP不用这个？因为TCP首部长度不固定，UDP首部长度固定）（UDP有存长度字段，代表UDP首部加报文数据的长度。TCP没有这种字段：为什么没有？估计是当时设计的时候没怎么想好。导致挖了个坑：沾包问题）
• 确认ACK：1位（1字节=8位）
• 同步SYN：1位
• 终止FIN：1位
• 窗口：2直接，告诉发生方，接受方能接受多好个字节
• 其他字段，不是重点，我这里只提了重要的几个字段握手与挥手用到的字段
  一图胜千言 图片来源
  

3.3 TCP差错校验

下次再说

3.4 虚连接与套接字（Socket）

虚连接概念：需要先建立连接再进行通信，但是TCP连接不是一条真正的物理连接
套接字Socket = （IP地址：端口号）
没具体接触socket编程，都被Spring封装好了，不深入。知道这个东西就好了

4. TCP可靠传输原理

TCP的特点之一：可靠传输
不管是TCP还是UDP，最后数据还是交给网络层的IP协议传输的。IP层尽最大努力交付。可靠交付得靠TCP自己。

4.1 停止等待协议

停止等待协议：每发送完一个分组就停止发送，等待对方确认，收到对方确认后再发送下一个分组
这里可以与UDP对比下，TCP为了保证可靠性，牺牲了实时性，我们一般都用过微信的视频通话，就是用的UDP，有时候我们可以明显看到画面偶尔不清晰，那是因为有数据包丢了。为了确保实时性而牺牲可靠性。但是对于视频通话来说并不影响。

当出现差错的是，也就是说某个报文，或者说数据因为各种原因，丢失了，或者说是太长时间没到，TCP协议协议自动重传请求（ARQ）服务再确认。用这种方式确保TCP的可靠传输。
如果后续受收到了超时的数据包，服务端也会响应，但是客户端不做任何响应

太长时间，多长时间算是太长，大概超过一个RTT时间（数据一次往返的时间），RTT时间是个动态的，与网络好坏有关

想上面那样发送一个分组，收到回复，再发送一个分组。再收到回复之前，客户端干等，太浪费宽带了。一般是发送多个连续发送多个分组
发送分组1，分组2，分组3.，不必发送成功分组1在发后续的，
而是连续发送流水线式作业。这样提高效率，但是会有问题。如果流水线尾出了点问题，没来得及处理，这时候流水线就得停下来（这是为什么流水线够工人一般上厕所得在规定时间的原因，因为不能停）。那计算机怎么处理的：见后面拥塞控制

4.1 连续ARQ（自动重传请求）协议

滑动窗口协议（上面的流水线式分组发送）是TCP的精髓所在，流量控制也和它有关
发送窗口：有接受方维护。窗口里的分组够连续发送出去，不必one by one(TCP的发送窗口单位是字节)
连续ARQ协议规定发送方每收到一个确认，就把发送窗口往后移一个位置
一般采用累积确认方式，例如我发送了1，2，3，4。接收方收到了1,2，3那么会回复3的确认。这个时候发送发就知道1，2，3发送成功，窗口向后移三位

滑动窗口协议具体

5. TCP流量控制与拥塞控制

TCP特点之一：流量控制与拥塞控制

5.1 流量控制

接收方让发送发不要发送太快，TCP首部里面有个窗口字段，是接收方用来控制发送方的发送窗口大小的。当就收发发现发送方发送太快，就会减少这个 窗口字段的值，以达到流量控制的效果

零窗口探测报文段：当接收方将 窗口置为0后，发送方不在发送，但是接收方处理完接收的数据后，又不会主动通知发送方，这个时候就需要发送方发送一个字节的数据去试探接收方（这个应该也可以用类似的方式来试探某一方是否宕机）
Nagle算法：当发送方收到第一个字符的确认后，将剩下缓存的数据全部发送，并对后续的数据进行缓存，收到回复后（或者数据已经达到了发送窗口的一半 ）再次发送

5.2 拥塞控制

拥塞： 某段时间，对网络中某一资源的需求超过了该资源所能一共的可用部分，网络的性能就要变坏
拥塞控制： 防止过多的数据注入到网络中，是网络中的路由器或链路不至于过载。

拥塞控制是全局性的的过程，流量控制指点对对通信量的控制

慢开始和拥塞避免：
发送方维持一个拥塞窗口（cwnd）的变量，拥塞窗口的大小取决于网络的拥塞程度，发送发让自己的发送窗口等于拥塞窗口

慢开始：由小到大逐渐增大发送窗口，没经过一个传输轮次，拥塞窗口加倍（1->2->4->8）
慢开始门限（ssthresh）：当小于门限是用慢开始算法，大于门限时用拥塞避免算法
拥塞避免：让拥塞窗口缓慢的增大，一次+1而不是加倍，是拥塞窗口按照现行增长

无论是哪个阶段，当出现网络拥塞（出现丢包的情况，没有按时收到确认）时，，将慢开始门限设置为当前发送窗口的一半。所以慢开始门限是动态变化的。 同时开始执行慢开始算法，也就是拥塞窗口从1开始（与后面的快恢复区别）

快重传和快恢复
快重传：接收方没收到一个失序的报文段马上发出重复确认（对比前面的累积确认），发送方收到了3次重复确认后立即方对方没收到的报文段

快恢复：当发送方连续收到3个重复确认时，将慢开始门限ssthresh减半，但是后续不执行慢开始算法（因为如果拥塞严重，就不会收到3个重复确认），而是执行拥塞避免算法，使拥塞窗口缓慢的线性增大

小结：最开始用慢开始算法 ，拥塞窗口指数增大，到达慢开始门限后，使用拥塞避免算法 加法增大，当出现收到三个重复确认（快重传）的情况（中途有丢包），执行快恢复算法（其实就是慢开始门限减半，在执行拥塞避免算法）

随机早期检测RED
这个不是网络层和运输层的算法，在路由器上，应该算是数据链路层
路由器的队列（用来缓存当前需要转发的包)维护两个数据：队列长度最小门限TH_min 和最大门限TH_max 。当一个分组到达是，RED先计算平均队列长度L_AV
算法规则：（1）若平均队列长度小于最小门限，则把新到达的分组放入队列进行排队（2）若超过最大门限，新分组直接丢弃（3）若在两者之间，按照概率丢弃
平均队列长度计算方式：一个比较厉害的算法（反正是使队列变化比较缓和）

6. TCP连接管理

TCP运输有三个阶段，建立连接（三次握手，客户端主动发起），数据传输（全双工，客户端可以向服务端传输，服务端也可以向客户端传输），连接释放（四次挥手，客户端主动发起）
但是我个人对四次挥手有个地方没有明白：四次挥手什么时候触发的，我们一般不用的时候是直接断开浏览器，或者关闭网页。那么挥手操作什么时候做的？ 我有得到一个答案：我们关闭浏览器，或者关闭这个页面的时候，浏览器在后台替我们做了挥手过程。我们直接杀死浏览器时，相当于客户端宕机的情况

6.1 三次握手

这种东西千言万语不如一张图
seq就是TCP首部里面的序号
ack是是首部里的确认好
SYN，ACK是对应的字段（注意大小写的区别）

由客户端主动发起
少一次握手行不行？ 不行，为了避免已经失效的连接请求报文段有传送到了接收方（就是说本来发起连接，但是可能因为网络原因对方迟迟没有给回应，然后我又重新发起连接成功了。但是这个时候上次的连接对方给了回应，但是这个回应是我不需要的。所以我不会理会。但是如果只有两次握手，那岂不是对方白白开启了一个连接？）

但是即使是三次握手，双方也不会明确知道对方知道对方知道对方知道，，，
红军蓝军进攻问题，但是为什么3次握手够了，因为我总不能无限握手下去，而且这不是进攻问题，进攻失败了就会牺牲。我这是传输数据，失败了我再传就好了。

6.2 四次挥手

由客户端主动发起

最后为什么要等待2MSL？，（MSL最长报文段寿命）确保服务端关闭了。如果服务端没有关闭会发送倒数第二个（FIN=1，ACK=1，seq=w，ack=u+1）连接给我，我再次发送最后一次挥手
少一次挥手行不行？ 我个人感觉少了1，3，4次挥手肯定不行，但是少第二次好像没什么问题？因为我把ACK=1放到第三次好像也没什么毛病，FIN-WAIT-2阶段，就是说客户端发送数据，但是可以接受服务端的数据。我觉得这个状态没有有关系吗（仅代表我个人看法） 不行。少了第二次。那么客户端不知道对方知道我要关闭了。会不断的发送第一次握手的

7. 小结

• 网络分层协议（TCP/IP分层和OSI分层）
• 三次握手过程（最常见），能否少一次
• TCP与UDP的对比
• 浏览器输入一个网址的过程

前面三个问题，文章都有涉及到
第四个问题，仅网络层是不足够回答这个问题
思路或者说可以涉及的知识点： 应用层的HTTP或HTTPS协议，DNS（域名服务协议）；运输层的TCP协议。网络层的IP协议（包括IP协议，ARP地址解析协议，RARP逆地址解析协议，IP地址分类）。服务器MVC响应流程；涉及到的知识点越细致，越详细当然最好

参考资料：计算机网络（第六版） 谢希仁
这本书很不错，推荐购买，买二手的（有一些笔记，但是就可能有的有点脏）还比较便宜。

												落霞与孤鹜齐飞，秋水共长天一色
												（诗句来源于滕王阁序）
												博主：五更依旧朝花落
												首次发布时间：2020年4月10日20:47:56
												最近更新时间：2020年5月9日15:06:25(更新了许多错别字)