Java~网络原理~TCP协议与UDP协议详解、TCP保证可靠性传输的措施（确认应答、握手挥手、滑动窗口、流量控制、拥塞控制）及如何提高网络利用率？

传输层概述

• 在网络层的IP协议中，IP首部有个字段是协议字段，这个协议字段就标识了上一层具体是什么协议，就可以识别数据部分是TCP内容还是UDP内容
• 同理，在传输层的TCP和UDP协议中，也有个端口号字段，这个端口号就标识了上一层应用层具体哪个程序来处理，数据部分要具体给哪个应用程序处理
• 在应用层，协议大多以客户端/服务端的形式运行。客户端是请求发起端，服务端是接受请求并处理的一端。服务端程序要提前启动，以便随时准备处理请求。
• 在UNIX系统中，这些服务端程序叫守护进程.比如HTTP的服务端程序是httpd（HTTP的守护进程）、ssh的服务端程序（SSH的守护进程）等
• TCP传输的数据包来时，客户端通过端口号来确定要给哪个守护进程，然后发送给守护进程来处理。

TCP协议

• TCP是面向连接的、可靠的协议。并且是流协议。使用TCP发送数据时，就像管道中没有间隔的流水。TCP可以提供可靠的传输，具备顺序控制、重发机制、流控制、拥塞控制等来保证可靠性。
• TCP相较于UDP，充分实现了各种控制功能，数据丢失会重发、顺序混乱的包会调整、网络拥堵时会进行流量控制，所以传输数据时非常可靠
• TCP面向连接：先建立通信连接，只有确定目标主机可以通信时才会发送数据

UDP协议

• UDP是无连接的、不可靠的协议。UDP发送的数据不能保证一定会到达。所以不具备可靠性。
• UDP的特点：上层的应用程序指定做什么UDP就做什么。收到数据后会立即在网络上进行转发，数据丢包不负责重发，遇上网络拥堵也不会进行流量控制，收到的数据顺序混乱也不会纠正，不关注很多细节的东西，比较简单高效，只有作为传输协议最基本的功能。
• UDP经常用于以下场景：即时通信（比如音频通话）、包数量比较少的通信（比如DNS查查询域名）、广播通信和一些特定的无线LAN应用通信
• 注意：TCP可靠，UDP不可靠并不代表TCP一定优于UDP。两者其实有自己的使用场景。TCP更多的是用于应用的可靠传输，数据不能丢失的情况。而UDP更多的用于高速传输和实时性要求比较高的通信或者广播通信上。就像打电话，如果使用TCP，数据丢失会重发，对面听到的声音会不流畅不连通，就无法正常交流。如果使用UDP，数据丢失不会重发，就不存在大幅度延迟的问题，即使可能会丢失数据，也只是影响小部分通话，对于实时性没有影响。
• 应用程序通过套接字（Socket）相关的API来设置对端的IP地址、端口号，来实现数据的发送和接收

端口号

• 数据链路中用MAC地址来识别同一链路中不同的计算机。IP中用IP地址来识别TCP/IP网络中互连的主机和路由器。传输层中也有类似的概念，就是端口号。端口号用来识别同一台计算机中不同的应用程序。
• 在TCP/IP中，仅仅通过端口号来判断是同一个通信会话是不够的，端口号只能判断是这个程度，如果要确定是同一个通信，需要5个信息：源IP地址、目标IP地址、协议号、源端口号、目标端口号。只要有一个不同，就认为不是同一个通信。

通信前获得端口号的两个办法

方法一：标准既定的端口号

• 有很多的端口号不能随意分配使用，都是被固定的。这些标准端口号一般由0到1023之间的数字分配而成，分别对应着很多著名的服务程序，如HTTP、FTP等（http的端口号是80），除了这些标准端口号，还有很多已经正式注册的端口号分布在1024-49151之间。
• 如果使用这些标准化的服务程序，标准号都是已经确定的，可以直接查到

方法二：时序分配法

• 操作系统动态的为客户端程序分配互不冲突端口号，比如每个建立一个TCP连接，就在以前的端口号上加1.这样即使同一个程序中建立了5个TCP连接，也可以分辨出来
• 服务端程序的端口号通过监听确定，客户端就是动态分配，交给操作系统全权管理

UDP首部格式

• UDP首部由源端口号、目标端口号、包长、校验和组成。UDP数据报格式如下，去除数据就是首部部分

• 源端口号、目标端口号：从哪个应用程序发出，具体又将数据送到哪个应用程序中，大小都是16位
• 包长度：UDP数据包长度是多少个字节
• 校验和：通过计算校验和可以确认数据是否正确、是否完整。UDP中有时不会用校验和，直接填入0

TCP首部格式

• TCP数据报格式如下。比UDP要复杂的多
  
• 源端口号、目标端口号：和UDP相同，都是表示从哪个应用程序发出，发到哪个应用程序中，都是16位
• 序列号：表示数据的位置。第一个字节序列号为1，第二个字节序列号为2…以此类推
• 确认应答号：下一次该接收哪个序列号的数据
• 数据偏移：表示TCP数据包哪个位置是数据部分，哪个位置是首部部分。
• 控制位：字长8位，每一个位置为1时都表示不同的含义，像网络是否拥堵、数据是否有效、是否收到数据、是否应该传递给上层连接等等
• 窗口大小：数据以窗口形式发送时数据的大小
• 校验和：TCP必须使用，UDP可有可无的，用来表示接收到的数据是否正确和完整
• 紧急指针：数据部分首位到紧急指针的地方是紧急数据。

TCP如何确保可靠性传输？有哪些措施？

TCP为了确保可靠性传输，采取了很多机制，如确认校验和、确认序列号、确认应答机制、数据重发、连接管理、窗口控制等

确认应答机制

• 发送端的数据到达目标主机时，接收端会返回一个已收到消息的通知，这个消息就是ACK（Positive Acknowled-gement）。ACK表示确定收到了消息。如果确定没有收到消息，会回复一个NACK.

• 发送端和接收端之间的确认应答就像两个人聊天，发送端对接收端说话（发送数据），接受端肯定回答表示听懂了（ACK），否定回答表示没听懂（NACK）.没有回答也是认为没听懂

• 没有回应时，发送端会等待特定时间，然后重发数据。否定回答会直接重发数据。

• 接收端没有收到数据或者接收端收到了数据但是回复的ACK在路上丢失，只要没有回应，发送端就会重发数据，如下图
  

• 目标主机接受数据时，由于发送端有重发机制，所以可能会反复接收到重复的数据。重复的数据在上层应用传输时会被放弃，即重复控制机制

• 重发数据、重复控制、包括确认应答机制都是依赖于序列号完成。

• 序列号是将数据的每一个字节按顺序编号，每次发送一部分。目标主机接收到数据后，会将自己下一次该接受的序列号作为应答返回。比如第一次发送数据序列号1-1000，目标主机接受到数据后会返回1001，如下图

重发超时的那个时间间隔是如何确定的？

• TCP在传输数据包时，每一次往返都会计算时间和一些偏差。这个时间和就是最小的时间间隔，基本都比这个时间和大一点，如下图
  

TCP连接的开启与关闭（三次握手、四次挥手）

• 建立连接（三次握手）：客户端先发送一个SYN包请求建立连接，服务器端回复一个ACK确认应答，同时也发送一个SYN包请求建立连接，客户端再回复一个ACK确认应答。连接就建立完成可以开始通信。
• 关闭连接（四次挥手）：客户端发送一个FIN包请求断开连接，服务器端回复一个ACK表示收到，然后再单独发送一个FIN包请求断开连接，客户端再回复一个ACK表示收到。这样连接就关闭了，无法通信。如下图
  
• TCP在建立连接时，会确定数据包的单位，即最大消息长度（MSS，Maximum Segment Size）,也就是数据段。数据段最理想的大小是不会被IP分片处理的最大长度
• MSS的大小又两边的主机计算确定，在建立连接时通过SYN包相互告知，然后选择最小的作为MSS，也就是一个段的大小

滑动窗口机制

• TCP在传输时，如果每发送一个段，就要等待一次应答。如果往返一次需要很长的时间，那么这种一发一答的形式就非常低效。
• 为了解决这个问题，TCP建立了滑动窗口机制。即每次发送不以一个段为单位，而是以多个段为一个窗口，以窗口为单位发送，发送一个窗口后，就等待窗口的应答。窗口的应答也是多个段的应答放在一起回复。（窗口的大小又接收端主机决定）
  
• 在窗口中，如果数据发送到了，但是返回的数据应答丢失了，不会进行数据重发，可以通过下一个应答确认。比如我在一个窗口中发送了两个段的数据，窗口应答返回时，第一个段的应答丢失了，但是第二个段的应答成功确认。那么也可以认为第一个段的数据接收成功。即窗口中少部分应答丢失时，可以通过下一个应答进行确认，不需要重发
  
• 但如果窗口中的某段数据丢失，没有发送成功，接收端在接受其他段的数据时，会返回丢失数据的确认应答。并且会一直发送这个应答，提醒发送端，当连续发送三次以上，发送端就会重新发送这段数据，接收端接收到这段丢失的数据后，会回复最新的确认应答，这种应答机制比超时等待重发更高效，所以被称为高速应答。如下图
  

流量控制机制

• 流控制：发送端根据接收端实际接受数据能力来控制发送数据的大小。目的是防止出现发送端发送的数据，接收端接受不了从而丢弃或无法接受数据的现象。
• 具体过程：主机A向主机B发送数据前，主机B会告诉主机A自己能接收数据的大小，主机A实际发送数据时，就不会超过这个大小，这个大小也就是窗口大小。
• 这个值在TCP数据包的首部中，有个字段专门表示窗口大小。发送端只要读取这个值就可以
• 在接受端主机中，有一个缓冲区，TCP传过来的数据都会暂时存储在缓冲区，在缓冲区快满了的时候，窗口大小就会变小，具体的值就会传给发送端。发送端根据接收端不断传过来的值对发送的窗口大小进行一个控制，这个过程就是流量控制机制。
  
• 如果接收端不指示窗口大小，发送端就不会发送数据，等待一段时间后会发送窗口探测包。如果探测包没有回应，通信就会停止

拥塞控制机制

• 为了避免所有的TCP连接一开始就发送大量的窗口数据导致网络拥堵，所以TCP在开始传输数据时，有一个慢启动的机制。

• 慢启动：开始传输数据时，定义一个拥塞窗口，初始化是1个数据段，然后随着通信的进行，每一次收到ACK确认应答，拥塞窗口的大小就+1.每次发送数据时，窗口的大小都从接收端指定的流控制窗口和拥塞窗口中选择最小的哪一个作为窗口大小进行发送数据。
  

• 如果遇到了超时重传，再次发送数据时拥塞窗口大小会重新初始化为1（相当于再次慢启动）

• 为了避免拥塞窗口越来越大，引入了慢启动阈值。只要拥塞窗口的大小超过阈值，就不再单纯+1，而是按照某种比例来进行放大窗口

• 高速重发时，慢启动阈值的大小会变成当时拥塞窗口大小的一半。总的变化如下图

• 一般情况下，窗口越大，网络吞吐量越高。如果发生了网络拥堵，吞吐量会大幅下降，然后再慢慢上升的一个过程。

如何提高网络资源利用率？（Negle算法、延迟应答）

Negle算法

• Negle算法就是如果还有发送的数据，但是发送的数据比较小的话，就延迟发送。
• 具体就是如果以下两个情况都不满足，就延迟发送，满足任何一个情况，就发送：
  1.已经发送的数据返回了确认应答
  2.可以发送最大长度的数据（MSS）时

延迟应答机制

• 如果接收端收到了数据就立即返回ACK,此时刚接受完数据，缓冲区剩余空间可能不大，因此流量窗口也很小，发送端再立马用非常小的流量窗口发送数据会降低网络资源利用率。所以采取了延迟策略
• 一般不是一发一答，而是两发一答，即发送两个最大数据段（MSS）的数据才会确认应答一次。其他情况都是延迟0.5秒再发送确认应答ACK
• 实际TCP传输中，绝大多数情况都是两个数据段返回一个ACK