计算机与其他网络设备相互通信，通信的双方在发送和接收数据包时必须基于相同的规则（例如：如何找到通信目标、如何发起通信、如何结束通信等规则都需要事先确定），我们将这种规则称为协议（Protocol）。
TCP/IP协议簇是 Internet 的基础，其是一系列网络协议的总称，例如：TCP、UDP、IP、FTP、HTTP、ICMP、SMTP等都属于TCP/IP协议族内的协议。
这些协议在计算机网络中自下而上被划分为四层：链路层、网络层、传输层和应用层。
- 链路层：
负责发送和接收ARP/RARP报文；
- 网络层：
该层包含IP协议、RIP协议(Routing Information Protocol)，主要负责数据包在主机之间的传输；
- 传输层：
主要负责定位处理数据的具体进程并转发数据（TCP协议提供可靠的数据流运输服务，UDP协议提供不可靠的数据服务）；
- 应用层
负责向用户提供应用程序，比如HTTP、FTP、Telnet、DNS、SMTP等；
在网络体系结构中网络通信的建立必须是在通信双方的对等层进行，不能交错。
在整个数据传输过程中，数据在发送端经过各层时都要附加上相应层的协议头和协议尾（仅链路层需要封装协议尾）。
UDP 与 TCP 两种传输协议是 TCP/IP 协议簇的核心成员。
一、UDP
UDP（User Datagram Protocol）全称是用户数据电报协议，是一种无连接的协议，提供不可靠的用户数据报服务，1980 年发布的 RFC 768 定义了 UDP 协议。
UDP数据结构
UDP数据结构如下图所示：
UDP 协议头中只包含 4 个字段：源端口、目的端口、UDP长度、UDP校验码，其中每一个字段都占 16 位，即 2 字节，共8个字节。
- 源端口
发送方进程的端口号，接收方可以使用该字段（不一定准确）向发送方发送信息（范围0-65535）；
- 目的端口
数据接收方的端口号（范围0-65535）；
- UDP长度
协议头和数据报中数据长度的总和，表示整个数据报的大小；
- UDP校验码
使用 IP 首部、UDP 首部和数据报中的数据进行计算，接收方可以通过校验码验证数据的准确性，发现传输过程中出现的问题；
UDP首部数据举例
常见的 DNS 协议就可以使用 UDP 协议获取域名解析的结果：
0000 ff 7c 00 35 00 23 c2 6e上述 UDP 首部中四个字段对应的值如下：
- 源端口 0xff7c = 65404
- 目的端口 0x0035 = 53
由于 DNS 协议使用的端口是 53，所以目的端口就是 53
- UDP长度 0x0023 = 35
- UDP校验码 0xc26e
UDP在数据传输中的位置
这里我们可以将应用到应用之间的传输过程分成两个部分：主机到主机的数据传输和主机到应用的数据转发。
- UDP 协议首部的
目的端口号用于定位处理数据的具体进程并转发数据； - UDP 协议底层的网络层IP协议（Internet Protocol）会负责数据包在主机之间的传输；
我们说 UDP 协议是传输层协议，但是真正在主机间完成数据传输工作的是 IP 协议，UDP 协议只起到了定位具体进程的作用。
UDP数据传输的特点
- 面向无连接
UDP 不需要与 TCP一样在发送数据前进行三次握手建立连接，UDP想发数据就直接发送了；并且UDP只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。
- 不可靠
首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠的；并且收到什么数据就传递什么数据，也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据；
再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据；即使网络条件不好，也不会对发送速率进行调整，这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如直播、电话会议等）就需要使用 UDP 而不是 TCP；
- 单播、多播、广播功能
由于 UDP 不会建立连接，因此它可以给任何人传递数据，不止支持一对一的传输方式，同样支持一对多、多对多、多对一的方式；
- UDP是面向报文的
发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层（UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界）；
- 头部开销小，传输数据高效
UDP 的头部开销小，只有八字节，在传输数据报文时是比较高效的（在某些实时性要求高的场景，例如直播、电话会议、媒体传输等场景经常使用 UDP协议）；
二、TCP
TCP（Transmission Control Protocol）协议全称是传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议，由RFC 793定义。
当用户查看网页或电子邮件时，希望看到的内容完整且顺序正确，不丢失任何内容；当下载文件时，希望获得的是完整的文件，而不仅仅是文件的一部分；以上应用场景的传输层协议均可采用TCP协议。
TCP数据结构
- 源端口、目标端口
发送方进程的端口号，数据接收方的端口号（范围0-65535）；
- 序号
主要是为了解决乱序问题（编好号才知道哪个先来，哪个后到）；
- 确认序号
发出去的包应该有确认，这样能知道对方是否收到，如果没收到就应该重新发送，这个解决的是不丢包的问题；
- 状态位
SYN 是发起一个链接，ACK 是回复，RST 是重新连接，FIN 是结束连接（TCP 是面向连接的，因此需要双方维护连接的状态，这些状态位的包会引起双方的状态变更）；
- 窗口大小
TCP 要做流量控制，需要通信双方各声明一个窗口，标识自己当前的处理能力；
TCP三次握手
TCP协议发送数据之前必须在通信的两端建立连接，建立连接的方法是TCP三次握手：
- 第一次握手
客户端向服务端发送连接请求报文；请求发送后，客户端便进入 SYN-SENT 状态；
- 第二次握手
服务端收到连接请求报文后，如果同意连接，则会发送一个应答，发送完成后便进入 SYN-RECEIVED 状态；
- 第三次握手
当客户端收到连接同意的应答后，还要向服务端发送一个确认报文；客户端发完这个报文后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。
为什么 TCP 建立连接需要三次握手，而不是两次？
TCP既要保证数据可靠传输，又要提高传输的效率，而用三次（客户端与服务端发送的报文都得到了响应，通信双方全都有来有回）恰恰满足了以上两方面的需求！
TCP四次挥手
TCP断开连接，也被称为四次挥手：
- 第一次挥手
A：B，我不玩了客户端A向服务端B发送连接释放请求；
- 第二次挥手
B：OK，A不玩了，知道了
服务端B 收到连接释放请求后，发送 ACK 包，并进入 CLOSE_WAIT 状态；
此时服务端B不再接收客户端A发送的数据，但服务端B 若此时还有没发完的数据会继续发送；
- 第三次挥手
B：A，我也不玩了，拜拜
服务端 B 向 A 发送连接释放请求，然后 B 便进入 LAST-ACK 状态；
- 第四次挥手
A：OK，B不玩了，拜拜
客户端A 收到释放请求后，向 服务端B 发送确认应答，此时 客户端A 进入 TIME-WAIT 状态；
客户端A的 TIME-WAIT状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有 B 的重发请求，就进入 CLOSED 状态。当 B 收到确认应答后，也便进入 CLOSED 状态。
TCP协议的特点
相比与UDP协议，TCP协议拥有面向连接、保证顺序、可靠传输、提供拥塞控制等特点。
为了保证顺序性，每个TCP数据包都有一个序号ID，在建立连接的时候会商定起始 ID 是什么，然后按照 ID 一个个发送；
为了保证不丢包，需要对发送的包都要进行应答，这里应答不是一个一个来的，而是会应答某个之前的 ID，表示都收到了，这种模式成为累计应答；
为了记录所有发送的包和接收的包，需要发送端和接收端分别缓存这些记录。
TCP发送端的缓存里是按照数据包的 序号ID 一个个排列，根据处理的情况分成四个部分：
- 发送并且确认的；
- 发送尚未确认的；
- 没有发送等待发送的；
- 没有发送并且暂时不会发送的；
在 TCP 协议中接收端会给发送端报一个窗口大小Advertised Window，这个窗口大小等于上面的第二、第三部分加和，超过这个窗口接收端处理不过来，暂时不能继续发送；
上图TCP发送端缓存队列中：
- 1、2、3 已发送并确认；
- 4、5、6、7、8、9 都是发送了还没确认；
- 10、11、12 是还没发出的；
- 13、14、15 是接收方没有空间，不准备发的。
TCP接收端缓存内容类型如下：
- 接收并且确认过的；
- 还没接收，马上就能接收的；
- 还没接收，也无法接收的；
上图TCP接收端缓存队列中：
- 1、2、3、4、5 是已经完成 ACK ；
- 6、7 是等待接收的，8、9 是已经接收还没有 ACK 的；
- 10、11、12 、13、14、15 是暂时无法接收的；
TCP发送端、接收端当前的状态如下（依据以上两个图）：
- 1、2、3 没有问题，双方达成了一致；
- 4、5 接收方响应 ACK 了，但是发送方尚未收到；
- 6、7、8、9 肯定都发了，而且8、9 已经到了，但6、7 尚未收到，出现了乱序，缓存着暂无法 ACK；
根据这个例子可以知道顺序问题和丢包问题都有可能存在：
假设4的ACK响应发送端收到了，5的ACK丢了；6、7的数据包丢了，该怎么办？
- 一种方法是超时重试，即对每一个发送了但是没有 ACK 的包设定一个定时器，超过了一定的事件就重新尝试；这个重试时间必须大于往返时间，但也不宜过长，否则超时时间变长，访问就变慢了；
例如：过一段时间，5、6、7 的ACK都超时了，发送端就会重新发送；接收方发现 5 原来接收过 于是丢弃 5，6、7收到了发送 ACK；
- 另一个快速重传的机制，即当接收方接收到一个序号大于期望的报文段时，就检测数据流之间的间隔，于是发送三个冗余的 ACK，客户端接收到之后，知道数据报丢失，于是重传丢失的报文段；
例如：接收方发现 6、8、9 都接收了，但是 7 没来（7丢了），于是发送三个 6 的 ACK，要求下一个是 7；客户端接收到 3 个ACK，就会发现 7 丢了，马上重发。
参考
UDP—RFC768:
https://tools.ietf.org/html/rfc768
TCP—RFC973：
https://tools.ietf.org/html/rfc793
Stackoverflow: UDP checksum calculation, Sep 2017
https://stackoverflow.com/questions/1480580/udp-checksum-calculation
百度百科—UDP：
https://baike.baidu.com/item/UDP/571511?fr=aladdin
百度百科—TCP：
https://baike.baidu.com/item/TCP/33012?fr=aladdin
TCP 和 UDP 的区别：
https://blog.csdn.net/zhang6223284/article/details/81414149#comments
= THE END =
文章首发于公众号”CODING技术小馆“，如果文章对您有帮助，可关注我的公众号。
文章首发于公众号”CODING技术小馆“，如果文章对您有帮助，可关注我的公众号。
文章首发于公众号”CODING技术小馆“，如果文章对您有帮助，可关注我的公众号。
