TCP(Transmission Control Protocol)，传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。主要特点如下：

• TCP 是面向连接的。

  就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接

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

• TCP 提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达。

• TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据。

• TCP 中的“流”（Stream），指的是流入进程或从进程流出的字节序列。

  “面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

1. 源端口号( 16 位):它(连同源主机 IP 地址)标识源主机的一个应用进程。

2. 目的端口号( 16 位):它(连同目的主机 IP 地址)标识目的主机的一个应用进程。这两个值加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址唯一确定一个 TCP 连接。

3. 顺序号 seq( 32 位):用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则 TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数，序号到达 2 的 32 次方 - 1 后 又从 0 开始。当建立一个新的连接时， SYN

4. 确认号 ack( 32 位):包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号加 1 。只有 ACK 标志为 1 时确认序号字段才有效。 TCP 为 应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必 须保持每个方向上的传输数据顺序号。

5. TCP 报头长度( 4 位):给出报头中 32bit 字的数目，它实际上指明数据从哪里开始。需要这 个值是因为任选字段的长度是可变的。这个字段占 4bit ，因此 TCP 最多有 60 字节的首部。然 而，没有任选字段，正常的长度是 20 字节。

6. 保留位( 6 位):保留给将来使用，目前必须置为 0 。

7. URG :为 1 表示紧急指针有效，为 0 则忽略紧急指针值。

8. ACK :为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。

9. PSH :为 1 表示是带有 PUSH 标志的数据，指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。

10. RST :用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些问题。

11. SYN :同步序号，为 1 表示连接请求，用于建立连接和使顺序号同步( synchronize )。

12. FIN :用于释放连接，为 1 表示发送方已经没有数据发送了，即关闭本方数据流。

13. 窗口大小( 16 位):数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源 方接收窗口大小。窗口大小是一个 16bit 字段，因而窗口大小最大为 65535 字节。

14. 校验和( 16 位):此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字 进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。

15. 紧急指针(16位):只有当URG标志置1时紧急指针才有效。TCP的紧急方式是发送端向另 一端发送紧急数据的一种方式。

16. 选项:最常见的可选字段是最长报文大小，又称为MSS(MaximumSegmentSize)。每个连 接方通常都在通信的第一个报文段(为建立连接而设置 SYN 标志的那个段)中指明这个选项， 它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充 位，使得报头长度成为整字数。

17. 数据: TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报 文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数 据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

TCP 对应的应用层协议

• FTP ：定义了文件传输协议，使用 21 端口。常说某某计算机开了 FTP 服务便是启动了文件传输服务。下载文件，上传主页，都要用到 FTP 服务。

• Telnet ：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于 DOS 模式下的通信服务。如以前的 BBS 是纯字符界面的，支持 BBS 的服务器将 23 端口打开，对外提供服务。

• • SMTP ：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么 SMTP 端口设置这个栏，服务器开放的是 25 号端口。

  • POP3 ：它是和 SMTP 对应，POP3 用于接收邮件。通常情况下，POP3 协议所用的是 110 端口。也是说，只要你有相应的使用 POP3 协议的程序（例如 Foxmail 或 Outlook），就可以不以 Web 方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是 163 邮箱就没有必要先进入网易网站，再进入自己的邮箱来收信）。

• HTTP ：从 Web 服务器传输超文本到本地浏览器的传送协议。

三次握手，简单来说，就是：

• 发送方：我要和你建立链接？

• 接收方：你真的要和我建立链接么？

• 发送方：我真的要和你建立链接，成功。

ACK :为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。

SYN :同步序号，为 1 表示连接请求，用于建立连接和使顺序号同步( synchronize )。

顺序号 seq( 32 位):用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则 TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数，序号到达 2 的 32 次方 - 1 后 又从 0 开始。当建立一个新的连接时， SYN 标志变 1

确认号 ack( 32 位):包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号加 1 。只有 ACK 标志为 1 时确认序号字段才有效。 TCP 为 应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必 须保持每个方向上的传输数据顺序号。

• 第三次握手：Client 收到确认后，检查ack是否为J+1，ACK是否为 1 。

第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。

客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

为了防止已失效的连接请求报文突然又传送到了服务端，因而产生错误，TCP 连接需要三次握手。

客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达 Server 。

• 若不采用“三次握手”，那么只要 Server 发出确认数据包，新的连接就建立了。由于 Client 此时并未发出建立连接的请求，所以其不会理睬 Server 的确认，也不与 Server 通信；而这时 Server 一直在等待 Client 的请求，这样 Server 就白白浪费了一定的资源。

• 若采用“三次握手”，在这种情况下，由于 Server 端没有收到来自客户端的确认，则就会知道 Client 并没有要求建立请求，就不会建立连接。

在 中，搜 关键字，也有非常好的解答。

• 这就很明白了，防止了服务器端的一直等待而浪费资源。

四次挥手，简单来说，就是：

• 发送方：我要和你断开连接！

• 接收方：我也要和你断开连接！

• 链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。

• 等待2MSL时间，客户端就可以放心地释放TCP占用的资源、端口号，此时可以使用该端口号连接任何服务器。

TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP 是全双工模式，这就意味着：

• 当主机 1 发出 FIN 报文段时，只是表示主机 1 已经没有数据要发送了，主机 1 告诉主机 2 ，它的数据已经全部发送完毕了；但是，这个时候主机 1 还是可以接受来自主机 2 的数据；当主机 2 返回 ACK 报文段时，表示它已经知道主机 1 没有数据发送了，但是主机 2 还是可以发送数据到主机 1 的。

• 当主机 2 也发送了 FIN 报文段时，这个时候就表示主机 2 也没有数据要发送了，就会告诉主机 1 ，我也没有数据要发送了，之后彼此就会愉快的中断这次 TCP 连接。

TCP 建立连接要进行三次握手，而断开连接要进行四次。这是由于 TCP 的半关闭造成的。因为 TCP 连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务，就发送一个 FIN 来向另一方通告将要终止这个方向的连接。

如果要正确的理解四次的原理，就需要了解四次挥手过程中的状态变化。

主动方=发送方；被动方=接收方。

状态前面的（主动方）（被动方），表示该状态属于谁。

• （主动方）FIN_WAIT_1 ：其实 FIN_WAIT_1 和 FIN_WAIT_2 状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：

  • 而当对方回应 ACK 报文后，则进入到 FIN_WAIT_2 状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK 报文。所以， FIN_WAIT_1 状态一般是比较难见到的，而 FIN_WAIT_2 状态还有时常常可以用 netstat 看到。

• （主动方）FIN_WAIT_2 ：上面已经详细解释了这种状态，实际上 FIN_WAIT_2 状态下的 Socket，表示半连接，也即有一方要求 close 连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK 信息)，稍后再关闭连接。

• （被动方）CLOSE_WAIT ：这种状态的含义其实是表示在等待关闭。即当对方 close 一个 Socket 后发送 FIN 报文给自己，你系统毫无疑问地会回应一个 ACK 报文给对方，此时则进入到 CLOSE_WAIT 状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close 这个 Socket ，发送 FIN 报文给对方，也即关闭连接。所以你在 CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。

• （被动方）LAST_ACK ：这个状态还是比较容易好理解的，它是被动关闭一方在发送 FIN 报文后，最后等待对方的 ACK 报文。当收到 ACK 报文后，也即可以进入到 CLOSED 可用状态了。

• 状态下，收到了对方同时带 FIN 标志和 ACK 标志的报文时，可以直接进入到 TIME_WAIT 状态，而无须经过 FIN_WAIT_2 状态。

  如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的 TCP 报文可能与新 TCP 连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的 TCP 连接的活跃报文全部死翘翘，2MSL 时间可以满足这个需求（尽管非常保守）！

  更多，可以看看知乎 的讨论。

• CLOSED ：表示连接中断。

建立连接后，两台主机就可以相互传输数据了。如下图所示：

• 上图给出了主机 A 分 2 次（分 2 个数据包）向主机 B 传递 200 字节的过程。

• 首先，主机 A 通过 1 个数据包发送 100 个字节的数据，数据包的Seq号设置为 1200 。主机 B 为了确认这一点，向主机 A 发送ACK包，并将Ack号设置为 1301 。

  • 为了保证数据准确到达，目标机器在收到数据包（包括 SYN 包、FIN 包、普通数据包等）包后必须立即回传ACK包，这样发送方才能确认数据传输成功。

  • 此时Ack号为 1301 而不是 1201，原因在于Ack号的增量为传输的数据字节数。假设每次Ack号不加传输的字节数，这样虽然可以确认数据包的传输，但无法明确 100 字节全部正确传递还是丢失了一部分，比如只传递了 80 字节。因此按如下的公式确认Ack号：Ack =Seq号 + 传递的字节数 + 1 。

    • 与三次握手协议相同，最后加 1 是为了告诉对方要传递的 Seq 号。

OK，让我们重新来看下 TCP 的整个过程。如下图所示：

TCP 数据传输丢失怎么办(T即CP重传，通过定时器实现)

因为各种原因，TCP 数据包可能存在丢失的情况，TCP 会进行数据重传。如下图所示：

• 上图表示通过 Seq 1301 数据包向主机 B 传递 100 字节的数据，但中间发生了错误，主机 B 未收到。经过一段时间后，主机 A 仍未收到对于 Seq 1301 的 ACK 确认，因此尝试重传数据。为了完成数据包的重传，TCP 套接字每次发送数据包时都会启动定时器，如果在一定时间内没有收到目标机器传回的 ACK 包，那么定时器超时，数据包会重传。上图演示的是数据包丢失的情况，也会有 ACK 包丢失的情况，一样会重传。

• 这个值太大了会导致不必要的等待，太小会导致不必要的重传，理论上最好是网络 RTT 时间，但又受制于网络距离与瞬态时延变化，所以实际上使用自适应的动态算法（例如 Jacobson 算法和 Karn 算法等）来确定超时时间。

  往返时间（RTT，Round-Trip Time）表示从发送端发送数据开始，到发送端收到来自接收端的 ACK 确认包（接收端收到数据后便立即确认），总共经历的时延。

• TCP 数据包重传次数，根据系统设置的不同而有所区别。有些系统，一个数据包只会被重传 3 次，如果重传 3 次后还未收到该数据包的 ACK 确认，就不再尝试重传。但有些要求很高的业务系统，会不断地重传丢失的数据包，以尽最大可能保证业务数据的正常交互。

  最后需要说明的是，发送端只有在收到对方的 ACK 确认包后，才会清空输出缓冲区中的数据。

将 TCP 与 UDP 这样的简单传输协议区分开来的是，它传输数据的质量。TCP 对于发送数据进行跟踪，这种数据管理需要协议有以下两大关键功能：

• 可靠性：保证数据确实到达目的地。如果未到达，能够发现并重传。

• 数据流控：管理数据的发送速率，以使接收设备不致于过载。

要完成这些任务，整个协议操作是围绕滑动窗口 + 确认机制来进行的。因此，理解了滑动窗口，也就是理解了 TCP 。

       滑动窗口协议，是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。

TCP 的滑动窗口解决了端到端的流量控制问题，允许接受方对传输进行限制，直到它拥有足够的缓冲空间来容纳更多的数据。

TCP将独立的字节数据当作流来处理。一次发送一个字节并接收一次确认显然是不可行的。即使重叠传输（即不等待确认就发送下一个数据），速度也还是会非常缓慢。

TCP消息确认机制如上图所示，首先，每一条消息都有一个识别编号，每一条消息都能够被独立地确认，因此同一时刻可以发送多条信息。设备B定期发送给A一条发送限制参数，制约设备A一次能发送的消息最大数量。设备B可以对该参数进行调整，以控制设备A的数据流。

为了提高速度，TCP并没有按照字节单个发送而是将数据流划分为片段。片段内所有字节都是一起发送和接收的，因此也是一起确认的。确认机制没有采用message ID字段，而是使用的片段内最后一个字节的sequence number。因此一次可以处理不同的字节数，这一数量即为片段内的sequence number。

TCP数据流的概念划分类别

假设A和B之间新建立了一条TCP连接。设备A需要传送一长串数据流，但设备B无法一次全部接收，所以它限制设备A每次发送分段指定数量的字节数，直到分段中已发送的字节数得到确认。之后，设备A可以继续发送更多字节。每一个设备都对发送，接收及确认数据进行追踪。

如果我们在任一时间点对于这一过程做一个“快照”，那么我们可以将TCP buffer中的数据分为以下四类，并把它们看作一个时间轴：

1. 已发送已确认 数据流中最早的字节已经发送并得到确认。这些数据是站在发送设备的角度来看的。如下图所示，31个字节已经发送并确认。

2. 已发送但尚未确认 已发送但尚未得到确认的字节。发送方在确认之前，不认为这些数据已经被处理。下图所示14字节为第2类。

3. 未发送而接收方已Ready 设备尚未将数据发出，但接收方根据最近一次关于发送方一次要发送多少字节确认自己有足够空间。发送方会立即尝试发送。如图，第3类有6字节。

4. 未发送而接收方Not Ready 由于接收方not ready，还不允许将这部分数据发出。

接收方采用类似的机制来区分已接收并已确认，尚未接受但准备好接收，以及尚未接收并尚未准备好接收的数据。实际上，收发双方各自维护一套独立的变量，来监控发送和接收的数据流落在哪一类。

TCP是一个可靠的传输协议，所以需要对数据进行确认。TCP协议里窗口机制有2种：一种是固定的窗口大小；一种是滑动的窗口。这个窗口大小就是我们一次传输几个数据，对所有数据帧按顺序赋予编号，发送方在发送过程中始终保持着一个发送窗口，只有落在发送窗口内的帧才允许被发送；同时接收方也维持着一个接收窗口，只有落在接收窗口内的帧才允许接收。这样通过调整发送方窗口和接收方窗口的大小可以实现流量控制。

TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间数据传输。每个TCP/IP主机支持全双工数据传输，因此TCP有两个滑动窗口：一个用于接收数据，另一个用于发送数据。TCP使用肯定确认技术，其确认号指的是下一个所期待的字节。

假定发送方设备以每一次三个数据包的方式发送数据，也就是说，窗口大小为3。发送方发送序列号为1、2、3的三个数据包，接收方设备成功接收数据包，用序列号4(窗口大小+1)确认。发送方设备收到确认，继续以窗口大小3发送数据。当接收方设备要求降低或者增大网络流量时，可以对窗口大小进行减小或者增加，本例降低窗口大小为2，每一次发送两个数据包。当接收方设备要求窗口大小为0，表明接收方已经接收了全部数据，或者接收方应用程序没有时间读取数据，要求暂停发送。发送方接收到携带窗口号为0的确认，停止这一方向的数据传输。

先看下面一张图来分析一下固定窗口大小有什么问题。

注意：这里应该是ack而不是ACK，ACK是控制位中的一位，为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。

这里我们可以看到假设窗口的大小是1，也是就每次只能发送一个数据只有接受方对这个数据进行确认了以后才能发送第2个数据。我们可以看到发送方每发送一个数据，接受方就要给发送方一个ACK对这个数据进行确认。只有接受到了这个确认数据以后发送方才能传输下个数据。 这样我们考虑一下如果说窗口过小，那么当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟。如果说窗口的大小定义的过大。我们假设发送方一次发送100个数据。但是接收方只能处理50个数据。这样每次都会只对这50个数据进行确认。发送方下一次还是发送100个数据，但是接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。所以我们就引入了滑动窗口机制，窗口的大小并不是固定的而是根据我们之间的链路的带宽的大小，这个时候链路是否拥护塞。接受方是否能处理这么多数据了。

结合下图看看滑动窗口是如何工作的

首先是第一次发送数据这个时候的窗口大小是根据链路带宽的大小来决定的。我们假设这个时候窗口的大小是3。这个时候接受方收到数据以后会对数据进行确认告诉发送方我下次希望手到的是数据是多少。这里我们看到接收方发送的ACK=3(这是发送方发送序列2的回答确认，下一次接收方期望接收到的是3序列信号)。这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到了2个。就知道第3个数据对方没有收到。下次在发送的时候就从第3个数据开始发。这个时候窗口大小就变成了2

这个时候发送方发送2个数据。

看到接收方发送的ACK是5就表示他下一次希望收到的数据是5，发送方就知道我刚才发送的2个数据对方收了这个时候开始发送第5个数据。

这就是滑动窗口的工作机制，当链路变好了或者变差了这个窗口还会发生变化，并不是第一次协商好了以后就永远不变了。

滑动窗口协议，是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。 只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。 收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。当发送窗口和接收窗口的大小都等于1时，就是停止等待协议。

计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。

通过拥塞控制来解决。拥堵控制，就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。

拥塞控制的方法主要有以下四种：

不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。

拥塞避免算法，让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1 ，而不是加倍，这样拥塞窗口按线性规律缓慢增长。

快重传，要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方），而不要等到自己发送数据时捎带确认。

快重传算法规定，发送方只要一连收到三个重复确认，就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半。

• 但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。

• 所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，然后执行拥塞避免算法。

UDP（User Data Protocol，用户数据报协议），是与 TCP 相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去。

• UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）。

• UDP 是面向报文的。

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

  对实时应用很有用，如 直播，实时视频会议等

• UDP 支持一对一、一对多、多对一和多对多的交互通信。

• UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

UDP在应用层协议中的应用

• DNS ：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。

• SNMP ：简单网络管理协议，使用 161 号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。

• TCP 是面向连接的；UDP 是无连接的。

• TCP 是可靠的；UDP 是不可靠的。

• TCP 只支持点对点通信；UDP 支持一对一、一对多、多对一、多对多的通信模式。

• TCP 是面向字节流的；UDP 是面向报文的。

• TCP 有拥塞控制机制；UDP 没有拥塞控制，适合媒体通信。

• TCP 首部开销(20 个字节)，比 UDP 的首部开销(8 个字节)要大。

TCP数据流模式和UDP数据报模式

所谓的“流模式”，是指TCP 发送端发送几次数据和接收端接收几次数据是没有必然联系的。

• 比如你通过 TCP 连接给另一端发送数据，你只调用了一次 write ，发送了 100 个字节，但是对方可以分 10 次收完，每次 10 个字节；你也可以调用 10 次 write ，每次 10 个字节，但是对方可以一次就收完。

• 原因：这是因为 TCP 是面向连接的，一个 Socket 中收到的数据都是由同一台主机发出，且有序地到达，所以每次读取多少数据都可以。

所谓的“数据报模式”，是指 UDP 发送端调用了几次 write ，接收端必须用相同次数的 read 读完。

• UDP 是基于报文的，在接收的时候，每次最多只能读取一个报文，报文和报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃。

• 原因：这是因为 UDP 是无连接的，只要知道接收端的 IP 和端口，任何主机都可以向接收端发送数据。这时候，如果一次能读取超过一个报文的数据，则会乱套。

• 域名解析， 转换成 IP ，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。

• DNS 协议运行在 UDP 协议之上，使用端口号 53 。

1. 找 DNS 服务器(本地域名、顶级域名、根域名)

• 区域传送时使用 TCP 协议。

  • 辅域名服务器会定时（一般是 3 小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用 TCP 而不是 UDP ，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。

  • TCP 是一种可靠的连接，保证了数据的准确性。

• 域名解析时使用 UDP 协议。

  • 客户端向 DNS 服务器查询域名，一般返回的内容都不超过 512 字节，用 UDP 传输即可。

    UDP 报文的最大长度为 512 字节。

  • 不用经过 TCP 三次握手，这样 DNS 服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向 DNS 服务器查询的时候使用 TCP ，但事实上，很多 DNS 服务器进行配置的时候，仅支持 UDP 查询包。

TCP和UDP都是位于传输层的协议，传输层负责将数据从发送端传输到接收端。

端口号（Port）标识了一台主机上正在进行通信的一个具体的应用程序，在TCP/IP协议中，使用源IP、源端口号、目的IP、目的端口号、协议号的五元组来标识一个通信，即我们只要标注出这五个数据，就能唯一确定一条通信线路。

• 0~1023：知名端口号，其中HTTP、FTP、SSH等这些广泛使用的应用层协议，端口号都固定在前1024个端口号之中。
• ：操作系统动态分配的端口号，客户端程序的端口号，会由操作系统在这个范围内进行分配。

其中知名端口号是为了方便使用，给某些服务器固定分配的端口号：

• SSH服务器：使用22端口
• FTP服务器：使用21端口
• HTTP服务器：使用80端口

因此用户在写自己的程序使用端口号的时候，应该避免这些知名端口号。

一个进程可以和多个端口号绑定，即这个进程可以通过这些端口号分别建立连接，实现通信，但是一个端口号只能绑定一个进程，假如绑定多个进程，这个端口号在通信时无法判断应该将数据具体交给哪个进程！

netstat是一个用来查看网络状态的重要工具，如果在Linux服务器的命令行上输入netstat显示没有该命令，则需要通过yum进行安装。

• n：拒绝显示别名，能以数字显示的全部转化为数字
• l：仅列出在Listen（监听）的服务状态
• p：显示建立相关链接的程序名
• t：仅显示TCP相关的选项
• u：仅显示UDP相关的选项
• a：（all）显示所有选项，默认不显示Listen相关

前两行是UDP的首部，也可以叫做UDP的报头，报头总共有8个字节。UDP的报头是定长报头，固定为8个字节，因此只要取出前八个字节即可实现报头与有效载荷的分离。

第一行的前16个比特位表示UDP数据报的源端口号，即数据报是从哪里发出的，后16位则表示的是目的端口号，即数据报需要向哪里发送。在内核中是使用哈希的方式通过端口号找到相对应的目标进程。

其中第二行的前16比特位代表UDP长度，表示的是整个数据报（UDP首部加上UDP数据）的最大长度，通过这个UDP长度，我们可以计算出该UDP报文的结尾在哪里。

第二行的后16比特位代表UDP的检验和，即对整个UDP数据报进行检验，在UDP协议下，如果检验和出错，该数据报会直接被丢弃。

1. 无连接：知道对端的IP和端口号就可以直接进行传输，并不需要像TCP那样经过三次握手建立通信连接，结束通信时再经过四次挥手断开连接。
2. 不可靠：没有确认机制，也没有重传机制；如果因为网络原因无法发送到对方，UDP协议层也不会给应用层返回任何的错误信息。
3. 面向数据报：一旦发送，就必须将整个数据报的全部内容完全发送出去，同时读端在读取数据时，要么读整个数据报，要么就不读，不能只读一半。因此UDP不能灵活控制读写数据的次数和数量。

我们可以用寄信的例子来理解UDP的传输过程：每封信都有严格的界限（被信封包好），同时在写信或读信的时候都是以整封信为单位，并不能只写半封信或者只读半封信。而且在寄信过程中，信件有可能丢失，但是信件丢失后双方都不知道这件事情。

应用层给UDP交付多长的报文，UDP就会原样发送，既不会对报文进行拆分，也不会将它们合并，假如发送端调用一次sendto方法，发送了100个字节，那么接收端也必须对应只能调用一次recvfrom方法，并一次性接收100字节，而绝不能循环调用10次recvfrom方法，每次接收10字节。

UDP其实并没有真正意义上的发送缓冲区，调用了sendto之后会直接交给内核，由内核将数据传给网络层协议后进行后续的传输工作。

但是UDP是具有接收缓冲区的，只是这个接收缓冲区并不能保证收到的UDP数据报的顺序与发送端发送的顺序一致，因为在网络的发送的过程中，路由选择会影响数据的传输时间；同时这个缓冲区一旦满了，溢出的UDP数据报会被直接丢弃，并且根据UDP的机制，发送端不会再重新发送这些已经溢出的数据。

UDP协议中UDP首部有一个16位的UDP长度，也就是说一个UDP数据报能传输的数据最大长度是64KB（包含了UDP首部），64KB在现在的网络环境下是一个非常小的容量，所以如果使用UDP要传输超过64KB的数据，就需要用户在应用层手动将数据分包，使用多个UDP数据报发送，并在接收端再手动将它们拼接起来。

首先需要说明的是4位报头长度，它表示该TCP头部有多少个32位bit位（即有多少个4字节），因此TCP头部的最大长度应该是(2^4-1) * 4 = 15 * 4 = 60个字节，又由示意图可以知道报头占据了20个字节，因此选项字段最多可以有40个字节。选项字段和TCP报头共同组成了TCP的头部，在读取数据时应该先读取20字节，取出4位报头长，如果4位报头长度的值为5，那么说明TCP首部长度只有4*5 = 20字节，刚刚读取的就是所有的头部内容，下面接着的就是数据内容；如果报头长度的值大于5，则后面还要读取一部分选项字段。

通过对比我们发现，TCP数据包格式中并没有像UDP数据报中的16位UDP长度字段来标识数据的整体大小，这与两者的传输方式有关，UDP是面向数据报传输，每次要传输一个完整的数据报，所以必须标出每个数据报的具体大小，但是TCP是面向字节流传输的，可以一个字节一个字节传输，因此TCP可以一个字节一个字节放在缓冲区就行了，应用层想读多少根据应用层来自行决定。通过TCP的16位检验和，可以判断数据完整性，因此TCP不需要在数据格式中添加具体的数据长度了。

因为TCP是安全的传输协议，因此它采用了确认应答机制，这种机制的可靠性体现在：只要收到了对应的应答，就可以认为，之前的数据对方已经收到了！

现在的ACK其实是可以携带数据的，但是我们在这里方便理解，就先认为它并不携带数据，只是对收到数据做出应答。所以在计算机通信中并不存在绝对可靠，因为ACK只能保证ACK前的数据收到了，但是最新的一条通信数据永远无法被ACK。如上图中的ACK2，就没有人可以保证它的可靠性啦。

32位序号：因为TCP是可靠传输，所以发送的信息顺序也要保证接收方接受的顺序一致，但是如果有多条数据，在发送过程中因为路由选择不同，一定是会有先发出的后到达，后发出的先到达的现象。所以就需要给数据进行编号，这样接收方根据编号再将数据进行排列，这样就可以保证数据报文的顺序了，32位序号应该有发送方在发送数据报之前填写完毕。

32位确认序号：我们已经知道了TCP是确认应答机制，所以如果发送方发送了三份报文，分别编号5,6,7。接收方也会返回三条ACK确认信息，我们怎么知道这三条ACK分别确认的是哪条报文呢？这里就要用到确认序号，但是这里有一个重要的点：ACK所携带的确认序号是报文序号 + 1,即确认5号报文的确认序号是6；确认6号报文的确认序号是7；确认7号报文的确认序号是8。原因是确认序号告知的是发送方，前面的报文我已经收到了，下一份报文应该从确认序号开始发送！如果在接收方发送ACK过程中，7,8两个ACK丢失，发送方只收到了9号ACK，发送方还会去发送6,7两份报文吗？不会！9号ACK代表这前面所有的报文接收方都收到了，发送方只需要继续从9号报文开始发送就行了！所以确认序号的存在，允许TCP中出现少量的丢包现象。假如发送方给接收方发送了0到10000号报文，但是只收到了确认序号为5000的ACK，发送方会认为：0~4999号报文接收方一定收到了，但是后面的报文无法保证，所以会从5000开始重新发送。

这里还会有一个高频的面试题：为什么TCP要成对出现序号和确认序号？只有序号不就行了吗？发送方在这里填写序号，接收方在这里填写确认序号即可。

原因是TCP也是全双工的通信协议，双方在建立通信后，都可以发送消息也都可以接收消息，当作为发送方时，自己要编写序号，同时要留意对方给自己返还的确认序号；但当自己作为接收方时，也要按对方填写的序号将收到的信息排序，并将自己确认收到的信息序号加1作为确认序号返还给对方。

16位窗口大小：发送方的接收缓冲区剩余空间的大小，通过这个可以实现流量控制。虽然TCP不像UDP那样，缓冲区溢出后，会导致丢包，因为TCP会有重传机制，但是传输过去的信息已经耗费了网络资源，再次传输会继续消耗网络资源，这对于网络通信是非常浪费的行为。因此我们设置了窗口大小，发送方可以在报文中告知对方，我的接收缓冲区剩余空间还有多少，这样等到接收方给发送方发送数据时，可以防止对方发送数据过多；而接收方在接收到消息后返还的ACK报文中也可以带上自己接受缓冲区剩余空间的大小，方便发送方控制自己的发送数据量。

TCP协议下，接收端会接收到大量形形色色的报文，怎么该辨别每个报文分别是干什么的呢？因此就需要六个标志位来帮助接收端识别自己接收的报文的身份。比如ACK报文的ACK标志位会被设置为1，当接收端发现之后，就知道这份报文是作为ACK确认发送过来的，就需要着重注意一下它的确认序号。

• URG：紧急指针是否有效
• ACK：确认号是否有效
• PSH：提示接收端应用程序立刻从TCP缓冲区将数据读走
• RST：对方要求重新建立连接；我们将携带RST标识的报文称为复位报文段
• SYN：请求建立连接；将携带SYN标识的报文称为同步报文段
• FIN：通知对方，本端即将关闭，将携带了FIN标识的报文称为结束报文段

这里SYN和ACK以及FIN我们应该都较为熟悉，重点介绍一下PSH、RST和URG三个标志位

PSH(Push)：是在提示接收端，接收端的接收缓冲区快要满了。因为经过上面的窗口大小我们知道，接收端返回的ACK中也会标上自己缓冲区的大小，所以发送端是可以知道接收端的剩余缓冲区还有多少，当发送端发现接收端的接收缓冲区大小快要满了，就会在报文上携带PSH标志位，来提醒接收端的应用层程序立即将接收缓冲区中的数据读取完毕，这样不会延误自己继续发送数据的效率。

RST(Reset)：即要求重新建立连接，我们举个例子来对它进行解释：

上图中①，②，③表示我们TCP建立连接的三次握手，其中①，②两份数据报丢失我们都不担心，因为此时并没有建立起来连接，所以只需要再次发送SYN重新建立连接就行了，但是如果③号报文，即客户端给服务器的ACK丢包，那问题就严重了。我们上文谈过ACK的确认应答机制并非绝对安全，永远有一条最新的数据是无法被确认的，③号的ACK就是这条数据。当客户端发出③号ACK后，就认为TCP连接已经建立，开始准备发送数据，但是如果发生了极小概率时间，该报文丢失了，那么就会产生一个信息差：客户端认为TCP连接已经建立，但是服务器没有收到客户端的ACK，认为三次握手失败，TCP连接建立失败！

此时客户端给服务器发送数据，服务器发现TCP并没有建立，对端还在给自己发送数据，就会意识到，在TCP连接建立过程中出现了问题，此时服务器就会给客户端发送一个报文，其中携带着RST标志位，告诉客户端，你要重新建立TCP连接！当客户端收到这份报文，就意识到TCP并没有建立成功，此时它就会停止发送数据，继续上面的三次握手，重新建立TCP连接了。同理，如果TCP传输过程中，客户端突然断开连接，并没有进行四次挥手，服务器还认为TCP连接存在，给客户端发了数据，客户端收到后，也会发送一个携带RST标志位的报文返给服务器，但是不同的是服务器看到这份报文后，就会断开连接了，因为建立连接永远是客户端向服务器请求，服务器是不会主动向客户端请求连接的。

URG(urgent)：（不重要，已经很少使用）如果我们发送的某些信息，发出后就后悔了，不想让对方收到这些信息，所以需要发出通知让对方不要接收刚才的消息，但是因为TCP的有序性，对方收到不要接收信息的通知一定是晚于接收信息到达对方那里的，所以需要一种打破按序到达的机制。打个比方，我们在医院的挂号处排队，先来的排在前面，但是这时来了一位急诊病人，我们就会让他先去挂号。URG标志位被设置后，说明这份报文中有些数据是需要被优先处理的。即16位紧急指针。16位紧急指针是个偏移量，将起始地址加上偏移量后，就可以指向紧急数据。我们可以找到紧急数据的起始地址，但是它并没有标识结束地址的信息，因此每次的紧急数据只能发送一个字节。

16位检验和：对整个TCP报文进行检验，如果发生错误，直接丢弃该报文，但是TCP有重传机制，我们并不担心报文错误的问题，假如1,2,3,4,5报文中3号报文发生了错误，被TCP丢弃掉了，此时只需要将ACK3传给发送方即可，因为发送方会从ACK携带的序号开始，把后面的报文再发一遍。

至此需要介绍的内容结束了，以上为笔者自己整理的学习笔记，可能其中有部分内容不太正确，也不太完整，还请大家指正