传输层

在学习HTTP等应用层协议时，为了便于理解，可以简单的认为HTTP协议是将请求和响应直接发送到了网络当中。但实际应用层需要先将数据交给传输层，由传输层对数据做进一步处理后再将数据继续向下进行交付，该过程贯穿整个网络协议栈，最终才能将数据发送到网络当中。

传输层负责可靠性传输，确保数据能够可靠地传送到目标地址。为了方便理解，在学习传输层协议时也可以简单的认为传输层协议是将数据直接发送到了网络当中。

再谈端口号

端口号的作用

端口号（Port）标识一个主机上进行网络通信的不同的应用程序。当主机从网络中获取到数据后，需要自底向上进行数据的交付，而这个数据最终应该交给上层的哪个应用处理程序，就是由该数据当中的目的端口号来决定的。

从网络中获取的数据在进行向上交付时，在传输层就会提取出该数据对应的目的端口号，进而确定该数据应该交付给当前主机上的哪一个服务进程。

因此端口号是属于传输层的概念的，在传输层协议的报头当中就会包含与端口相关的字段。

五元组标识一个通信

在TCP/IP协议中，用“源IP地址”，“源端口号”，“目的IP地址”，“目的端口号”，“协议号”这样一个五元组来标识一个通信。

比如有多台客户端主机同时访问服务器，这些客户端主机上可能有一个客户端进程，也可能有多个客户端进程，它们都在访问同一台服务器。

而这台服务器就是通过“源IP地址”，“源端口号”，“目的IP地址”，“目的端口号”，“协议号”来识别一个通信的。

• 先提取出数据当中的目的IP地址和目的端口号，确定该数据是发送给当前服务进程的。
• 然后提取出数据当中的协议号，为该数据提供对应类型的服务。
• 最后提取出数据当中的源IP地址和源端口号，将其作为响应数据的目的IP地址和目的端口号，将响应结果发送给对应的客户端进程。

通过netstat命令可以查看到这样的五元组信息。

其中的Local Address表示的就是源IP地址和源端口号，Foreign Address表示的就是目的IP地址和目的端口号，而Proto表示的就是协议类型。

协议号 VS 端口号

• 协议号是存在于IP报头当中的，其长度是8位。协议号指明了数据报所携带的数据是使用的何种协议，以便让目的主机的IP层知道应该将该数据交付给传输层的哪个协议进行处理。
• 端口号是存在于UDP和TCP报头当中的，其长度是16位。端口号的作用是唯一标识一台主机上的某个进程。
• 协议号是作用于传输层和网络层之间的，而端口号是作用于应用层于传输层之间的。

端口号范围划分

端口号的长度是16位，因此端口号的范围是0 ~ 65535：

• 0 ~ 1023：知名端口号。比如HTTP，FTP，SSH等这些广为使用的应用层协议，它们的端口号都是固定的。
• 1024 ~ 65535：操作系统动态分配的端口号。客户端程序的端口号就是由操作系统从这个范围分配的。

认识知名端口号

常见的知名端口号

有些服务器是非常常用的，这些服务器的端口号一般都是固定的：

• ssh服务器，使用22端口。
• ftp服务器，使用21端口。
• telnet服务器，使用23端口。
• http服务器，使用80端口。
• https服务器，使用443端口。

查看知名端口号

我们可以查看/etc/services文件，该文件是记录网络服务名和它们对应使用的端口号及协议。

说明一下： 文件中的每一行对应一种服务，它由4个字段组成，每个字段之间用TAB或空格分隔，分别表示“服务名称”、“使用端口”、“协议名称”以及“别名”。

两个问题

一个端口号是否可以被多个进程绑定？

一个端口号绝对不能被多个进程绑定，因为端口号的作用就是唯一标识一个进程，如果绑定一个已经被绑定的端口号，就会出现绑定失败的问题。

一个进程是否可以绑定多个端口号？

一个进程是可以绑定多个端口号的，这与“端口号必须唯一标识一个进程”是不冲突的，只不过现在这多个端口唯一标识的是同一个进程罢了。

我们限制的是从端口号到进程的唯一性，而没有要求从进程到端口号也必须满足唯一性，因此一个进程是可以绑定多个端口号的。

netstat与iostat

netstat命令

netstat是一个用来查看网络状态的重要工具。

其常见的选项如下：

• n：拒绝显示别名，能显示数字的全部转换成数字。
• l：仅列出处于LISTEN（监听）状态的服务。
• p：显示建立相关链接的程序名。
• t(tcp)：仅显示tcp相关的选项。
• u(udp)：仅显示udp相关的选项。
• a(all)：显示所有的选项，默认不显示LISTEN相关。

查看TCP相关的网络信息时，一般选择使用nltp组合选项。

而查看TCP相关的网络信息时，一般选择使用nlup组合选项。

如果想查看LISTEN状态以外的连接信息，可以去掉l选项，此时就会将处于其他状态的连接信息显示出来。

iostat命令

iostat主要用于输出磁盘IO和CPU的统计信息。

其常见的选项如下：

• c：显示CPU的使用情况。
• d：显示磁盘的使用情况。
• N：显示磁盘列阵（LVM）信息。
• n：显示NFS使用情况。
• k：以KB为单位显示。
• m：以M为单位显示。
• t：报告每秒向终端读取和写入的字符数和CPU的信息。
• V：显示版本信息。
• x：显示详细信息。
• p：显示磁盘分区的情况。

比如我们要查看磁盘IO和CPU的详细信息。

CPU属性值说明：

• %user：CPU处在用户模式下的时间百分比。
• %nice：CPU处在带NICE值的用户模式下的时间百分比。
• %system：CPU处在系统模式下的时间百分比。
• %iowait：CPU等待输入输出完成时间的百分比。
• %steal：管理程序维护另一个虚拟处理器时，虚拟CPU的无意识等待时间百分比。
• %idle：CPU空闲时间百分比。

pidof

pidof命令可以通过进程名，查看进程id。

例如，我们用pidof命令查看我们自己编写的一个死循环进程。

pidof命令可以配合kill命令快速杀死一个进程。

UDP协议

UDP协议格式

UDP的位置

网络套接字编程时用到的各种接口，是位于应用层和传输层之间的一层系统调用接口，这些接口是系统提供的，我们可以通过这些接口搭建上层应用，比如HTTP。我们经常说HTTP是基于TCP的，实际就是因为HTTP在TCP套接字编程上搭建的。

而socket接口往下的传输层实际就是由操作系统管理的，因此UDP是属于内核当中的，是操作系统本身协议栈自带的，其代码不是由上层用户编写的，UDP的所有功能都是由操作系统完成，因此网络也是操作系统的一部分。

UDP协议格式

UDP协议格式如下：

• 16位源端口号：表示数据从哪里来。
• 16位目的端口号：表示数据要到哪里去。
• 16位UDP长度：表示整个数据报（UDP首部+UDP数据）的长度。
• 16位UDP检验和：如果UDP报文的检验和出错，就会直接将报文丢弃。

我们在应用层看到的端口号大部分都是16位的，其根本原因就是因为传输层协议当中的端口号就是16位的。

UDP如何将报头与有效载荷进行分离？

UDP的报头当中只包含四个字段，每个字段的长度都是16位，总共8字节。因此UDP采用的实际上是一种定长报头，UDP在读取报文时读取完前8个字节后剩下的就都是有效载荷了。

UDP如何决定将有效载荷交付给上层的哪一个协议？

UDP上层也有很多应用层协议，因此UDP必须想办法将有效载荷交给对应的上层协议，也就是交给应用层对应的进程。

应用层的每一个网络进程都会绑定一个端口号，服务端进程必须显示绑定一个端口号，客户端进程则是由系统动态绑定的一个端口号。UDP就是通过报头当中的目的端口号来找到对应的应用层进程的。

说明一下： 内核中用哈希的方式维护了端口号与进程ID之间的映射关系，因此传输层可以通过端口号得到对应的进程ID，进而找到对应的应用层进程。

如何理解报头？

操作系统是C语言写的，而UDP协议又是属于内核协议栈的，因此UDP协议也一定是用C语言编写的，UDP报头实际就是一个位段类型。

例如：

UDP数据封装：

• 当应用层将数据交给传输层后，在传输层就会创建一个UDP报头类型的变量，然后填充报头当中的各个字段，此时就得到了一个UDP报头。
• 此时操作系统再在内核当中开辟一块空间，将UDP报头和有效载荷拷贝到一起，此时就形成了UDP报文。

UDP数据分用：

• 当传输层从下层获取到一个报文后，就会读取该报文的钱8个字节，提取出对应的目的端口号。
• 通过目的端口号找到对应的上层应用层进程，然后将剩下的有效载荷向上交付给该应用层进程。

UDP协议的特点

UDP传输的过程就类似于寄信，其特点如下：

• 无连接：知道对端的IP和端口号就直接进行数据传输，不需要建立连接。
• 不可靠：没有确认机制，没有重传机制；如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息。
• 面向数据报：不能够灵活的控制读写数据的次数和数量。

注意： 报文在网络中进行路由转发时，并不是每一个报文选择的路由路径都是一样的，因此报文发送的顺序和接收的顺序可能是不同的。

面向数据报

应用层交给UDP多长的报文，UDP就原样发送，既不会拆分，也不会合并，这就叫做面向数据报。

比如用UDP传输100个字节的数据：

• 如果发送端调用一次sendto，发送100字节，那么接收端也必须调用对应的一次recvfrom，接收100个字节；而不能循环调用10次recvfrom，每次接收10个字节。

UDP的缓冲区

• UDP没有真正意义上的发送缓冲区。调用sendto会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作。
• UDP具有接收缓冲区。但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致；如果缓冲区满了，再到达的UDP数据就会被丢弃。
• UDP的socket既能读，也能写，因此UDP是全双工的。

为什么UDP要有接收缓冲区？

如果UDP没有接收缓冲区，那么就要求上层及时将UDP获取到的报文读取上去，如果一个报文在UDP没有被读取，那么此时UDP从底层获取上来的报文数据就会被迫丢弃。

一个报文从一台主机传输到另一台主机，在传输过程中会消耗主机资源和网络资源。如果UDP收到一个报文后仅仅因为上次收到的报文没有被上层读取，而被迫丢弃一个可能并没有错误的报文，这就是在浪费主机资源和网络资源。

因此UDP本身是会维护一个接收缓冲区的，当有新的UDP报文到来时就会把这个报文放到接收缓冲区当中，此时上层在读数据的时就直接从这个接收缓冲区当中进行读取就行了，而如果UDP接收缓冲区当中没有数据那上层在读取时就会被阻塞。因此UDP的接收缓冲区的作用就是，将接收到的报文暂时的保存起来，供上层读取。

UDP使用注意事项

需要注意的是，UDP协议报头当中的UDP最大长度是16位的，因此一个UDP报文的最大长度是64K（包含UDP报头的大小）。

然而64K在当今的互联网环境下，是一个非常小的数字。如果需要传输的数据超过64K，就需要在应用层进行手动分包，多次发送，并在接收端进行手动拼装。

基于UDP的应用层协议

• NFS：网络文件系统。
• TFTP：简单文件传输协议。
• DHCP：动态主机配置协议。
• BOOTP：启动协议（用于无盘设备启动）。
• DNS：域名解析协议。

当然，也包括你自己写UDP程序时自定义的应用层协议。

（注：本文部分摘自《计算机网络 谢希仁》）

目录

1.传输控制协议TCP

1.1TCP的主要特点：

1.1.1面向连接的运输层协议

1.1.2每一条TCP连接只能有两个端点，每一条TCP链接只能是点对点的（一对一）

1.1.3TCP提供可靠交付的服务

1.1.4TCP提供全双工通信

1.1.5面向字节流

1.2与TCP有关的面试问题

2.用户数据报协议UDP

2.1UDP协议的主要特点：

---

 

1.传输控制协议TCP

1.1TCP的主要特点：

1.1.1面向连接的运输层协议

（1）TCP的连接

TCP的许多特性都与TCP是面向连接的这个基本特性有关，因此要对TCP的连接有更清楚的了解。

每一条TCP连接唯一地被通信两端的两个端点所确定，所谓的端点就是套接字（或插口）。

套接字的表示方法：在点分十进制的IP地址后面写上端口号，例如IP地址是192.3.4.5，端口号是80，那么套接字就是（192.3.4.5：80） 。

（2）TCP的连接建立

三次握手：TCP建立连接的过程叫做握手，握手需要在客户端和服务器之间交换三个TCP报文段。此过程如下：

（3）tcp的连接释放

 四次挥手过程如下：

（4）tcp的有限状态机

可以看我之前的这篇文章，这里不再赘述。

TCP连接的状态——TIME_WAIT的存在意义https://blog.csdn.net/m0_54355780/article/details/121190546

1.1.2每一条TCP连接只能有两个端点，每一条TCP链接只能是点对点的（一对一）

1.1.3TCP提供可靠交付的服务

（1）可靠传输的工作原理

①停止等待协议：

“停止等待”就是每发送完一个分组就停止发送，等待对方确认。在收到确认后再发送下一个分组。

• 无差错的情况下：一端发送，另一端等待并接收
• 出现差错的情况：一端在一段时间（会设置有超时计时器）一直没有收到确认，认为自己刚发送的内容丢失，于是重新发送，这就叫超时重传。这里需要注意三点：第一，发送完自己的分组需暂时保留自己的副本，以防超时重传；第二，分组和确认分组要编号，从而确认哪些分组收到确认，哪些分组没有收到确认；第三，超时计时器设置的重传时间应当比数据在分组传输的平均往返时间长一些。
• 确认丢失和确认迟到：  
• 信道利用率 

等值等待协议的信道利用情况如下图：

 

为了提高效率，发送方可以不使用低效率的停止等待协议，使用流水线传输，流水线传输就是发送方可以连续发送多个分组，不必每发完一个分组就停下来等待对方的确认。

②连续的ARQ协议

连续ARQ协议规定：发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方采用累计确认的方式，也就是说：接收方不必对收到分组逐个发送确认，而是在收到几个分组之后，对按序到达的最后一个分组发送确认。

（2）可靠传输的实现

①超时重传时间的选择

报文段的往返时间RTT：采用自适应算法，记录一个报文段发出的时间，以及收到相应确认的时间。这两个时间之差就是RTT。

平滑的往返事件RTTs：RTT的一个加权平均往返时间

上式的α值在RFC 6298推荐为0.125 。

超时重传时间RTO：报文每重传一次，就把超时重传时间RTO增大一些，取新的重传时间为旧的重传时间的2倍。当不再发生报文段的重传时，才根据下面的式子计算超时重传时间。

②选择确认SACK

如果收到的报文没有差错，但是未按序号，中间还缺少一些数据，使用选择确认可以只传送缺少的数据而不重传已经确认到达接收方的数据。

要使用选择确认，需在TCP首部的选项中加上“允许SACK”的选项，并且双方必须事先商定好。

但是首部最长40字节，如果要报告5个字节块的边界信息，那么5个边界需要2*5*4=40个字节来表述，再加上一个字节指明SACK选项命令一个字节指明SACK占用多少字节，这就一共需要42字节，超出首部长度。因此大多数的实现还是需要重传全部的数据块。

③流量控制

流量控制的目的：让发送方的发送速率不要太快，从而让接收方来的及接收

• 滑动窗口：在 TCP 的报头中有一个字段叫做接收通告窗口，这个字段由接收端填充，是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。所以发送端就会有一个发送窗口，这个发送窗 口的大小是由接收端填充的接收通告窗口的大小决定的，并且窗口的位置会随着发送端数据 的发送和接收到接收端对数据的确认而不断的向右滑动，将之称为滑动窗口。（TCP的滑动窗口以字节为单位）p3-p1=A的发送窗口；p2-p1=已发送但尚未收到确认的字节数；p3-p2=允许发送但尚未发送的字节数。此外，需要注意的是，并不是发送方将数据直接发给接收方，而是发送方的应用进程把字节流写入TCP的发送缓存，发送缓存用来暂时存放发送应用程序传送给发送方TCP准备发送的数据以及TCP已发送出但尚未收到确认的数据。接收方的应用进程从TCP的接收缓存中读取字节流，接收缓存用来暂时存放按序到达但尚未被接收应用程序读取的数据以及为按序到达的数据。最后在滑动窗口的部分知识中需要注意三点：第一，同一时刻，发送方的发送端口并不总是和接收方的接收窗口一样大，其会根据网络拥塞情况适当减少自己的窗口值；第二，不按序到达的数据，先临时存放在接收缓存中，等到缺少的字节收到后，再按序交付给上层的应用进程；第三，TCP接收方要有累计确认的功能。
• TCP的传输效率：TCP报文段的发送时机有三个控制机制：第一种，缓存中存放数据达到MSS（最大报文段长度）字节时，就组装成一个TCP报文段发送；第二种，发送方应用进程指明要求发送报文段；第三种，发送方的一个计时期限到了，就把当前已有 缓存数据并且<=MSS装入报文段发送出去。

④拥塞控制

• 满开始：由小到大逐渐增大拥塞窗口数值。
• 拥塞避免：为了防止拥塞窗口增长过大引起网络拥塞，设置慢开始门限。然后拥塞避免的算法思路就是让拥塞窗口缓慢增大，即每经过一个往返时间RTT就把发送方的拥塞窗口加一。
• 快速重传：接收方不要等待中积极发送数据的时候再进行对之前数据的捎带确认，而是收到数据立即发送确认。快重传算法规定：发送方一连收到三个重复的确认，就应当进行快重传。
• 快速恢复：当出现超时的时候，不启动慢开始，而是执行快恢复算法。发送方调整门限值=出现超时的cwnd(拥塞窗口)/2。

 

1.1.4TCP提供全双工通信

1.1.5面向字节流

流式服务的特点：TCP 字节流的特点，发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系，应用程序对数据的发送和接收是没有边界限制的。

1.2与TCP有关的面试问题

（1）为什么时三次握手，可不可以是两次握手，为什么？

如果是两次握手，那么如果出现这种情况：发送端发送请求连接报文，但是由于在网络中出现了滞留并没有按时到达接收端，等到一段时间发送端再次发送连接请求报文，接收端接收之后并发送确认连接。这样两次握手建立连接1。但是之前在网络中滞留的连接请求报文并没有丢失，于是发送给接收端，接收端误以为建立连接，于是就回复确认建立连接，所以此时又建立了连接2，但是发送端并不会给连接2发送数据，所以接收端一直处于等待，就会浪费接受端许多资源。

三次握手也可以是四次握手：接收端在回复确认建立连接报文的时候，将其分成两个报文段，一个是回复对发送端的连接确认，一个是发送自己的同步报文段。

（2）三次握手时可能出现什么攻击？

可以参考下面这篇文章：

TCP三次握手有哪些漏洞？https://www.cnblogs.com/HuiH/p/12599048.html可能出现的攻击有三种：SYN flood的攻击，TCP全连接攻击，Land攻击。

（3）四次挥手的过程可以用三次完成吗？

关闭连接时，服务器端收到FIN报文，并不会立刻关闭SOCKET,先回复ACK报文，等到服务器端的所有报文都发送完了，才发送FIN报文。所以不能三次完成，将ACK和FIN不能放在一起发送。

（4）对于三次握手四次挥手的面试题，可以看看这个文章

面试官，不要再问我三次握手和四次挥手https://zhuanlan.zhihu.com/p/86426969

（5）同一个端口可不可以被一个 TCP 和一个 UDP 的应用程序同时使用？

可以。原因是端口的唯一性标识是：端口号+协议名称。所以TCP和UDP的端口完全没有任何关系，协议内部端口号唯一。

追问：程序在连接到端口时，怎么知道此时从该端口进来的数据是tcp的还是udp的呢？

操作系统根据接收的IP数据包的首部内的8位协议来判断这是什么报文，从而直接交给相关的内核进程或者协议栈处理。

追问：一个端口是否可以绑定多个端口号？

可以。一个进程可以打开多个文件描述符，每个文件描述符对应一个端口号，所以一个进程可以绑定多个端口号。Linux会给每个socket分配一个唯一的文件描述符，通过这个文件描述符来区分对应的套接字。

追问：一个端口号是否可以被多个进程绑定？

不可以。但是在父子进程中可以实现多进程绑定一个端口号，因为子进程具有父进程的文件描述符副本，可以处理绑定到同样的端口上的连接

追问：一个端口可以同时连接多个TCP和多个UDP吗？

一个端口可以建立多个TCP连接，所谓的同一个端口是指服务器端的ip和port不变，但是只要客户端的ip和port不同就可以。一个端口同一时间只能绑定一个socket。UDP是面向无连接的，所以不存在多个UDP连接，只是服务端接收UDP数据需要绑定一个端口，一个socket只能绑定一个端口而已。

（如果还不是很清楚这方面的问题，可以参考下面几篇文章）

TCP和UDP使用同一端口通信https://blog.csdn.net/szm1234/article/details/116994450一个端口号可以同时被两个进程绑定吗？https://zhuanlan.zhihu.com/p/280672302#:~:text= 由上述结果可知：TCP、UDP可以同时绑定一个端口8888，但是一个端口在同一时刻不可以被TCP或者UDP绑定2次。,原因如下： TCP和UDP传输协议监听同一个端口后，接收数据互不影响，不冲突。快狗二面 一个端口可以 同时TCP 又UDP 吗？https://cloud.tencent.com/developer/article/1813256

（6）同一个应用程序可以创建多个套接字吗？

端口是唯一的，系统中任一个端口只能被一个程序占用。一个程序可以创建多个Socket，但多个Socket是不能共用端口的。

（7）什么是 TCP 粘包，如何解决？

定义：指的是多个报文数据内容融合在一起被接受

解决方案：

①循环接收、发送；即就是一次send,一次recv……

②设置分割标志。

③在头部加上长度控制，然后读取的时候只读取头部信息中指定的长度。

（8）为什么UDP数据包不发生粘包，而TCP会出现粘包？

TCP协议是面向链接的，收发两端都必须要有成对的socket,因此发送端为了将多个发往接收端的包更有效的发送，使用了优化的方法nagle算法。

面向流的服务是没有消息保护边界的。

UDP协议是无连接，面向消息的，支持一对多的模式，所以接收端的套接字缓冲区采用链式结构记录每一个到达的UDP包。

面向消息的通信是由消息保护边界的。

（9）如果接收端填充的接收通告窗口为 0，发送端接下来怎么处理？

接收端通告的窗口大小变成0，发送端会发一个1字节的段，这一个字节段可以是下一字节的数据，如果没有新的数据段发送的时候，就发一个ack，强制接收端重新宣告下一个期望的字节和窗口大小。如果接收方回复窗口大小仍然为零，则发送方的探测定时器加倍。没有收到ACK时，发送探测包的最大次数之后连接超时。

（10）什么叫糊涂窗口综合征？

糊涂窗口综合症是指当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者兼而有之；就会使应用进程间传送的报文段很小，特别是有效载荷很小； 极端情况下，有效载荷可能只有1个字节；传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象。

要解决这个问题，发送方要把数据累计成足够大的报文段，等到其到达接收方缓存区的一半大小，再发送报文。接收方等待一段时间，使得自己的接收缓存区中能够容纳一个最长的报文段或缓存区有一半空闲，然后再去发送确认报文。

（11）在 TCP 的实现中广泛使用的 Nagle 算法是什么？

若发送应用进程，把要发送的数据逐个字节的送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个发送报文段发送出去。

（12）TIME_WAIT 状态存在的原因？

①保证发送端发送的最后一个ACK报文段能够到达接收端，从而避免接收端因为收不到ACK报文段而不按照正常步骤进入CLOSED状态。

②使本链接持续的时间内所产生的所有报文都从网络中消失，避免下一个新连接中出现旧的连接请求报文段。

2.用户数据报协议UDP

2.1UDP协议的主要特点：

（1）UDP是无连接的，可以减少开销和发送数据之前的时延。

（2）UDP使用尽最大努力交付，不保证可靠交付，主机不需要维持复杂的连接状态表。

（3）UDP是面向报文的，一次交付一个完整的报文。

（4）UDP没有拥塞控制，因此网络出现的拥塞不会使得源主机的发送速率降低。

（5）UDP支持一对一、一对多、多对一、多对多的交互通信。

（6）UDP的首部开销小，只有八字节。

 

 

 

UDP协议

UDP（User Datagram Protocol）：用户报文协议
没有任何特点
和TCP对比：不可靠、无连接、面向报文
1. 网络的基本情况就是不可靠的

1. 没有谁能保证数据一定是可以发送到对方的，可能丢失（丢包)
2. 即使数据发送给对方了，也不能保证数据就是无差错的（不考虑有人故意修改数据的情况)
3. 依次发送多个数据后，不能保证接收方按照发送顺序接收到数据（乱序)，每次数据的发送，都是一次独立的寻找路径的过程

2. UDP作为一种最简单的传输层协议，基本上没有做什么的操作来帮助用户处理复杂的网络环境，所以UDP保留下来这种不可靠的特性。

3. UDP报文的头信息（定长的（8字节））

4. 校验和（checksum）的作用和工作机制

1. 判断收到的报文（数据）是否出现差错的
2. 利用hash函数的原理︰通过设计一种hash函数，达到冲突率很低的一种情况
   发送端:checksum(payload)=>校验和1 （把校验和1填写到UDP的header 中）
   接收端:checksum(payload)=>校验和2
   比较校验和2和header 中的校验和1：如果不等，payload在传输过程中一定出现差错了；如果相等，大概率payload没有出现出错
3. 针对校验和可以对上的情况，正常接收数据。
   针对校验和对不上的情况，直接丢弃包: UDP不是特别可靠

5.UDP协议栈的作用

1. 计算校验和
2. 填写正确的header信息
3. 把 header + payload一起交给网络层 （重点:UDP没有发送缓冲区）
4. 网络层发送数据到网卡
5. send方法返回
   重点:我们在应用层调用send方法时send方法返回了，就意味着数据已经到达网络中

接收到数据之后

1. 计算校验和
2. 解包
3. 通知指定的进程，数据已经到达…这段期间，进程可能还暂时来不及过来取数据。所以UDP协议栈需要找个地方把数据暂存一会儿。UDP协议栈中有接收缓冲区。

6. UDP有接收缓冲区，没有发送缓冲区
用户发送多少数据，UDP也会发送多少数据，所以UDP是面向报文的
UDP发送数据无需任何准备工作，随时随地可以发送:寄信vs打电话，所以UDP是无连接的

7. 面向数据报文导致的一个后果:
由于底层(物理层＋网络层)）都对一次发送的数据有大小限制。如果强行发送大于限制的数据，就会出现数据被截断。
全双工:同一个信道是双向的。

8. UDP协议的最适用场景
对实时性要求较高，对可靠性要求较低的场景
实时聊天（语音、视频聊天)
UDP支持广播。如果有广播需求，也可以考虑用UDP。

TCP协议

TCP（Transmission Control Protocol）：传输控制协议

目标:

1. 以进程为单位传递数据
2. 追求可靠性

什么是可靠性?

TCP只能保证尽自己最大的可能，把数据有序地发送给对方。但不能保证一定能发送给对方。

1. 尽可能去发送给对方
2. 即使发不过去，也有反馈
3. 保证对方接收是有序的
4. 保证对方不会收到差错数据
5. TC会设计一些机制，来尽可能的优化网络，提高对方收到的可能性

TCP使用什么样的机制，来保证可靠性——确认应答机制

1. TCP发送的数据，一般被称为segment(数据段)
2. 应答: acknowledge

1. 如果发送方同时发送了多条segment，应答进行了多次应答。发送方如何得知，接收方收到的是哪一次的segment?
   编号机制:发送方为发送的数据做编号，应答的时候带上对应编号即可。
2. 如果接收方没有收到数据，则不会应答;或者接收方应答了，但应答丢包了
   总之:发送方没有收到对应的应答。则认为对方没有收到数据——超时重传机制

TCP协议的header格式

1. 和UDP不同，TCP的header 不是定长的。
2. 哪个或者哪些字段，可以保证接受方的TCP协议栈进行解包工作?
   4位header长度
3. 根据源port+目标port做分用
4. 到目前为止，TCP发送的 segment有两种:（1.携带数据segment，⒉.应答segment），TCP协议并没有把两种作用的segment进行不同格式的设计，而是进行统一的设置了!
   那具体怎么区分本次segment是否有应答的作用呢?
   ack ==1时segment有应答功能；ack == 0时segment没有应答功能
5. segment的可能情况:（1）光携带数据；（2）携带数据＋应答（网络中合并数据的发送，可以提高网络发送的效率）
6. 32位序号：SN（Sequence Number）
   32位确认序号：ASN（Acknowledge Sequence Number）

SN和ASN书写规则

1. TCP为发送的每个字节都进行编号(只是payload，没有header)[h ello]
   h: 108(随便选的) ，e: 109 ，l: 110， l: 111， o: 112
2. TCP协议栈在建立连接时，会随机一个初识序列号(Initial Sequence Number lSN)lSN : 108
3. 发送的时候，header 中的SN填写的是 payload 中的第一个字节的序列号
   [ hello ]
   SN: 108
   接收方是知道长度是5的，所以，接收方如果收到数据，则表示108 - 112已经全部收到了
4. ASN应该如何填写？填写的是接收方期望收到的下一个字节的数据
   上述例子中，接收方要应答的话ASN应该填写113。隐含的意思就是113之前的所有数据，已经全部接收到了。
   
5. 如果发送方超过一定时间都没有收到应答，则可能
   
   发送方的处理逻辑是一致的。超时之后，直接重传即可(重传的数据不会丢失)，不需要区分情况
6. 如果乱序到达怎么办？
   
   对于发送方，收到了一个应答segASN = x时，发送方是怎么理解这个信号的?
   对方已经收到收到了x-1之前的所有数据了。
   TCP协议是有接收缓冲区的，保证对方接收是有序的（接收端可以重新整理数据，接收过得数据不再接收）

如果超时之后，重传对方仍然没有收到，怎么办?

继续重传，直到到达一个阈值（假设6次）。如果6次，我都没有收到应答。我就认为不需要再努力的，放弃:

1. 尽人事，试图通知对方，连接异常关闭了——通过发送一个reset segment(另一种)。
   rst = 1，reset segment
   rst = 0，不是reset segment
2. 通知我们的应用层，数据发送失败了。（Java中是通过异常的方式通知的，会收到一个IOException (SocketException)描述reset connection）

连接管理（Connection Message）

为什么需要连接（连接是什么抽象）？

1. 作为TCP协议栈，是需要维护一个接收缓冲区的。
   （1）保证整理乱序到达的数据
   （2）在数据暂时未被应用层读走之前，临时保存数据
2. 作为TCP协议栈，是需要维护一个发送缓冲区的。
   因为要考虑重发的可能性，所以未应答的数据不能直接扔掉，所以需要一个空间暂存
   例：send(‘hello’)成功，代表数据被发送到OS的TCP协议栈的发送缓冲区中
3. 作为TCP协议栈
   发送方时，需要维护已经发送的SN
   接收方时，需要维护应该应答的SN

上述3点，足以说明:TCР协议栈，为了保证之前的那些机制可用，必须为每个信道，维护一组相关的数据! !

建立连接阶段的必要性

1. 由于TCP是追求可靠性的，所以TCP在正式发送数据之前，想验证下对象是否能收到我的数据。
   类比:寄信＋电话
2. Connection对象，有一部分信息是无法独立知道的，需要双方进行有效信息的同步

TCP的建立连接,需要双方交换几次信息——三 次——三 次握手
[常见面试题]为什么是三次?为什么不是两次，为什么不是四次，为什么不是其他次?

4种segment:数据segment、应答segment (ack= 1)、reset segment (rst= 1)、同步segment (syn= 1)

1. 什么是连接&为什么TCP需要有连接，UDP就没有连接。
   逻辑上对信道的抽象。物理上各自内存中维护的信道相关的一组数据。
   因为TCP为了追求可靠性引入一系列机制（确认应答机制，超时重传机制），为了这些机制能正常的工作，使得TCP必须引入连接的概念。
2. 为什么要有建立连接阶段的必要性
   1. 互相确认对象在线
   2. 双方同步必要的初识信息
3. 为什么是三次握手。