70、TCP协议的三次握手与四次挥手

70.1、TCP报文结构

  1、源端口号：表示发送端端口号，字段长为16位。
  2、目标端口号：表示接收端口号，字段长为16位。
  3、序列号：表示发送数据的位置，字段长为32位。每发送一次数据，就累加一次该数据字节数的大小。
  注意：序列号不会从0或1开始，而是在建立连接时由计算机生成的一个随机数作为其初始值，通过SYN包发送给接收端主机。然后再将每次转发过去的字节数累加到初始值上表示数据的位置。
  4、确认应答号：表示下一次应该收到的数据的序列号，字段长为32字节。发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。
  序号的优点：
  （1）保证报文按序到达。
  （2）保证可靠性。
  （3）保证效率。
  （4）精准的报告哪些报文已经收到，哪些需要重传。
  5、首部长度：该字段长度为4位，单位为4字节（32位）。TCP首部长度不包括选项的话，是20个字节，20/4=5，5的二进制序列：0101，报头长度也叫数据偏移，所以该字段可以设置为5，选项字段最大的是40字节，所以，TCP首部长度为最大为20+40=60字节，该字段可以设置的最大长度为60/4=15。
  6、保留：该字段主要是为了以后扩展时使用，其长度为4位。一般设置为0，即使收到的包在该字段不为0，此包也不会丢弃。
  7、控制位：字段长为6，每一位从左到右分别为：URG、ACK、PSH、RST、SYN、FIN。当对应的值为1，表示有具体含义。

  8、窗口大小：接收缓冲区的大小，TCP不允许发送超过此处所示大小的数据。
  9、校验和：发送端填充，CRC校验，接收校验不通过，则认为数据有问题。和UDP的区别是，UDP校验的是数据本身，TCP校验的不仅包含TCP首部，而且包含TCP数据部分。
  10、紧急指针：只有在URG为1时有效，该字段为1表示本报文的段中的紧急数据的指针。
  11、选项：用于提高TCP的传输性能。需要根据首部长度进行控制，其最大长度为40字节。

70.2、TCP三次握手以及四次挥手用到的字段

  1、序列号seq
  占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生，给字节编上序号后，就给每一个报文段指派一个序号，序列号seq就是这个报文段中的第一个字节的数据编号。
  2、确认号ack
  占4个字节，期待收到对方下一个报文段的第一个数据字节的序号，序列号表示报文段携带数据的第一个字节的编号，而确认号指的是期望接受到下一个字节的编号，因此当前报文段最后一个字节的编号+1即是确认号。
  3、确认ACK
  占1个比特位，仅当ACK=1，确认号字段才有效。ACK=0，确认号无效。
  4、同步SYN
  连接建立时用于同步序号。当SYN=1，ACK=0表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使用SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接收报文，SYN这个标志位只有在TCP建立连接才会被置为1，握手完成后SYN标志位被置为0。
  5、终止FIN
  用来释放一个连接。

70.3、TCP三次握手

  step1:第一次握手
  建立连接时，客户端发送SYN包到服务器，其中包含客户端的初始序号seq=x，并进入SYN_SENT状态，等待服务器确认。（其中，SYN=1，ACK=0，表示这是一个TCP连接请求数据报文；序号seq=x，表明传输数据时的第一个数据字节的序号是x）。
  step2:第二次握手
  服务器收到请求后，必须确认客户的数据包。同时自己也发送一个SYN包，即SYN+ACK包，此时服务器进入SYN_RECV状态。（其中确认报文段中，标识位SYN=1，ACK=1，表示这是一个TCP连接响应数据报文，并含服务端的初始序号seq(服务器)=y，以及服务器对客户端初始序号的确认号ack(服务器)=seq(客户端)+1=x+1）。
  step3:第三次握手
  客户端收到服务器的SYN+ACK包，向服务器发送一个序列号(seq=x+1)，确认号为ack(客户端)=y+1，此包发送完毕，客户端和服务器进入ESTAB_LISHED(TCP连接成功)状态，完成三次握手。
  未连接队列
  在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包(syn=j)开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包时，删除该条目，服务器进入ESTAB_LISHED状态。

70.4、四次挥手过程（关闭客户端到服务器的连接）

  step1：第一次挥手
  首先，客户端发送一个FIN，用来关闭客户端到服务器的数据传送，然后等待服务器的确认。其中终止标志位FIN=1，序列号seq=u。
  step2：第二次挥手
  服务器收到这个FIN，它发送一个ACK，确认ack为收到的序号加一。
  step3：第三次挥手
  关闭服务器到客户端的连接，发送一个FIN给客户端。
  step4：第四次挥手
  客户端收到FIN后，并发回一个ACK报文确认，并将确认序号seq设置为收到序号加一。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
  客户端发送FIN后，进入终止等待状态，服务器收到客户端连接释放报文段后，就立即给客户端发送确认，服务器就进入CLOSE_WAIT状态，此时TCP服务器进程就通知高层应用进程，因而从客户端到服务器的连接就释放了。此时是“半关闭状态”，即客户端不可以发送给服务器，服务器可以发送给客户端。
  此时，如果服务器没有数据报发送给客户端，其应用程序就通知TCP释放连接，然后发送给客户端连接释放数据报，并等待确认。客户端发送确认后，进入TIME_WAIT状态，但是此时TCP连接还没有释放，然后经过等待计时器设置的2MSL（2倍报文最大生存时间）后，才进入到CLOSE状态。
  【注意】中断连接端可以是 Client 端，也可以是 Server 端。
  假设 Client 端发起中断连接请求，也就是发送 FIN 报文。Server 端接到 FIN 报文后，意思是说"我 Client 端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭 Socket，可以继续发送数据。所以你先发送 ACK，"告诉 Client 端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候 Client 端就进入FIN_WAIT 状态，继续等待 Server 端的 FIN 报文。当 Server 端确定数据已发送完成，则向 Client 端发送 FIN 报文，"告诉 Client 端，好了，我这边数据发完了，准备好关闭连接了"。Client 端收到 FIN 报文后，“就知道可以关闭连接了，但是他还是不相信网络，怕 Server 端不知道要关闭，所以发送 ACK 后进入 TIME_WAIT 状态，如果 Server端没有收到 ACK 则可以重传。”Server 端收到 ACK 后，"就知道可以断开连接了"。Client端等待了 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭，那好，我 Client 端也可以关闭连接了。Ok，TCP连接就这样关闭了！

70.5、为什么需要三次握手，两次不可以吗？或者四次、五次可以吗？

  我们来分析一种特殊情况，假设客户端请求建立连接，发给服务器SYN包等待服务器确认，服务器收到确认后，如果是两次握手，假设服务器给客户端在第二次握手时发送数据，数据从服务器发出，服务器认为连接已经建立，但在发送数据的过程中数据丢失，客户端认为连接没有建立，会进行重传。假设每次发送的数据一直在丢失，客户端一直SYN，服务器就会产生多个无效连接，占用资源，这个时候服务器可能会挂掉。这个现象就是我们听过的“SYN的洪水攻击”。
  总结：第三次握手是为了防止：如果客户端迟迟没有收到服务器返回确认报文，这时会放弃连接，重新启动一条连接请求，但问题是：服务器不知道客户端没有收到，所以他会收到两个连接，浪费连接开销。如果每次都是这样，就会浪费多个连接开销。
  也是为了防止失效的连接请求报文段突然又传送到服务器，因而产生错误。

70.6、为什么是四次挥手，而不是三次或是五次、六次？

  确保数据能够完成传输。
  关闭连接时，当收到对方的 FIN 报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭 SOCKET，也即你可能还需要发送一些数据给对方之后，再发送 FIN 报文给对方来表示你同意现在可以关闭连接了，所以它这里的 ACK 报文和FIN 报文多数情况下都是分开发送的。
  TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP 是全双工模式，这就意味着，当主机 1 发出 FIN 报文段时，只是表示主机 1 已经没有数据要发送了，主机 1 告诉主机 2，它的数据已经全部发送完毕了；但是，这个时候主机 1 还是可以接受来自主机 2 的数据；当主机 2 返回 ACK 报文段时，表示它已经知道主机 1 没有数据发送了，但是主机 2 还是可以发送数据到主机 1 的；当主机 2 也发送了 FIN 报文段时，这个时候就表示主机 2 也没有数据要发送了，就会告诉主机 1，我也没有数据要发送了，之后彼此就会愉快的中断这次 TCP 连接。

70.7、time_wait 状态产生的原因？

  1）、可靠地实现 TCP 全双工连接的终止
  我们必须要假想网络是不可靠的，你无法保证你最后发送的 ACK 报文会一定被对方收到，因此对方处于 LAST_ACK 状态下的 SOCKET 可能会因为超时未收到 ACK 报文，而重发 FIN报文，client 必须维护这条连接的状态（保持 time_wait，具体而言，就是这条TCP 连接对应的（local_ip, local_port）资源不能被立即释放或重新分配）以便可以重发丢失的 ACK，如果主动关闭端不维持 TIME_WAIT 状态，而是处于 CLOSED 状态，主动关闭端将会响应一个 RST，结果 server 认为发生错误，导致服务器端不能正常关闭连接。所以这个TIME_WAIT 状态的作用就是用来重发可能丢失的 ACK 报文。所以，当客户端等待 2MSL（2倍报文最大生存时间）后，没有收到服务端的 FIN 报文后，他就知道服务端已收到了 ACK报文，所以客户端此时才关闭自己的连接。
  2）、允许老的重复分节在网络中消逝
  2MSL可以使本连接持续的时间内所有所产生的报文段都从网络中消失。这样就可以使下一个新的连接中不会出现旧的连接的请求报文段。
  如果 TIME_WAIT 状态保持时间不足够长 (比如小于2MSL)，第一个连接就正常终止了。第二个拥有相同四元组(local_ip, local_port, remote_ip,remote_port)的连接出现（建立起一个相同的 IP 地址和端口之间的 TCP 连接），而第一个连接的重复报文到达，干扰了第二个连接。TCP 实现必须防止某个连接的重复报文在连接终止后出现，所以让TIME_WAIT 状态保持时间足够长 (2MSL)，连接相应方向上的 TCP 报文要么完全响应完毕，要么被丢弃。建立第二个连接的时候，不会混淆。

70.8、如果网络连接中出现大量 TIME_WAIT 状态所带来的危害？

  如果系统中有很多 socket 处于 TIME_WAIT 状态，当需要创建新的 socket 连接的时候可能会受到影响，这也会影响到系统的扩展性。
  之所以 TIME_WAIT 能够影响系统的扩展性是因为在一个 TCP 连接中，一个 Socket如果关闭的话，它将保持 TIME_WAIT 状态大约 1-4分钟。如果很多连接快速的打开和关闭的话，系统中处于 TIME_WAIT 状态的 socket 将会积累很多，由于本地端口数量的限制，同一时间只有有限数量的 socket 连接可以建立，如果太多的socket 处于TIME_WAIT状态，你会发现，由于用于新建连接的本地端口太缺乏，将会很难再建立新的对外连接。

70.9、TCP如何保证传输的可靠性？

  0、在传递数据之前，会有三次握手来建立连接。
  1、应用数据被分割成 TCP 认为最适合发送的数据块（按字节编号，合理分片）。这和UDP完全不同，应用程序产生的数据报长度将保持不变。(将数据截断为合理的长度)
  2、当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。(超时重发)
  3、当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒 。(对于收到的请求，给出确认响应) (之所以推迟，可能是要对包做完整校验)。
  4、TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。(校验出包有错，丢弃报文段，不给出响应，TCP 发送数据端，超时时会重发数据)
  5、既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此TCP 报文段的到达也可能会失序。如果必要，TCP 将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。(对失序数据进行重新排序，然后才交给应用层)
  6、既然 IP 数据报会发生重复，TCP 的接收端必须丢弃重复的数据。(对于重复数据，能够丢弃重复数据)
  7、TCP 还能提供流量控制。TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。(TCP 可以进行流量控制，防止较快主机致使较慢主机的缓冲区溢出) TCP 使用的流量控制协议是可变大小的滑动窗口协议。
  8、TCP 还能提供拥塞控制。当网络拥塞时，减少数据的发送。

70.10、TCP 建立连接之后怎么保持连接（检测连接断没断）？

  有两种技术可以运用。一种是由 TCP 协议层实现的 Keepalive 机制，另一种是由应用层自己实现的 HeartBeat 心跳包。
  1、在 TCP 中有一个 Keep-alive 的机制可以检测死连接，原理很简单，当连接闲置一定的时间（参数值可以设置，默认是 2 小时）之后，TCP 协议会向对方发一个 keepalive探针包（包内没有数据），对方在收到包以后，如果连接一切正常，应该回复一个 ACK；如果连接出现错误了（例如对方重启了，连接状态丢失），则应当回复一个 RST；如果对方没有回复，那么，服务器每隔一定的时间（参数值可以设置）再发送 keepalive 探针包，如果连续多个包（参数值可以设置）都被无视了，说明连接被断开了。
  2、心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。由应用程序自己发送心跳包来检测连接的健康性。客户端可以在一个 Timer 中或低级别的线程中定时向服务器发送一个短小精悍的包，并等待服务器的回应。客户端程序在一定时间内没有收到服务器回应即认为连接不可用，同样，服务器在一定时间内没有收到客户端的心跳包则认为客户端已经掉线。  

71、TCP流量控制(滑动窗口机制)

  滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。
  所谓滑动窗口协议，自己理解有两点：1）、“窗口”对应的是一段可以被发送者发送的字节序列，其连续的范围称之为“窗口”；2）、“滑动”则是指这段“允许发送的范围”是可以随着发送的过程而变化的，方式就是按顺序“滑动”。在此之前要先了解以下前提：
  1、TCP 协议的两端分别为发送者 A 和接收者 B，由于是全双工协议，因此 A 和 B 应该分别维护着一个独立的发送缓冲区和接收缓冲区，由于对等性（A发B收 和 B发A收），我们以 A 发送 B 接收的情况作为例子；
  2、发送窗口是发送缓存中的一部分，是可以被 TCP 协议发送的那部分，其实应用层需要发送的所有数据都被放进了发送者的发送缓冲区；
  3、发送窗口中相关的有四个概念：已发送并收到确认的数据（不在发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之中）、允许发送但尚未发送的数据以及发送窗口外发送缓冲区内暂时不允许发送的数据；
  4、每次成功发送数据之后，发送窗口就会在发送缓冲区中按顺序移动，将新的数据包含到窗口中准备发送；

71.1、流量控制

  流量控制方面主要有两个要点需要掌握。一是TCP利用滑动窗口实现流量控制的机制；二是如何考虑流量控制中的传输效率。
  1、流量控制
  所谓流量控制，主要是接收方传递信息给发送方，使其不要发送数据太快，是一种端到端的控制。主要的方式就是返回的ACK中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送：

  这里面涉及到一种情况，如果B已经告诉A自己的缓冲区已满，于是A停止发送数据；等待一段时间后，B的缓冲区出现了富余，于是给A发送报文告诉A我的rwnd大小为400，但是这个报文不幸丢失了，于是就出现A等待B的通知||B等待A发送数据的死锁状态。为了处理这种问题，TCP引入了持续计时器（Persistence timer），当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍为0，则重设持续计时器，继续等待。
  2、传递效率
  一个显而易见的问题是：单个发送字节单个确认，和窗口有一个空余即通知发送方发送一个字节，无疑增加了网络中的许多不必要的报文（请想想为了一个字节数据而添加的40字节头部吧！），所以我们的原则是尽可能一次多发送几个字节，或者窗口空余较多的时候通知发送方一次发送多个字节。对于前者我们广泛使用Nagle算法，即：
  1）、若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的字节先缓存起来；
  2）、当发送方收到第一个字节的确认后（也得到了网络情况和对方的接收窗口大小），再把缓冲区的剩余字节组成合适大小的报文发送出去；
  3）、当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段；
  对于后者我们往往的做法是让接收方等待一段时间，或者接收方获得足够的空间容纳一个报文段或者等到接受缓存有一半空闲的时候，再通知发送方发送数据。

71.2、拥塞控制

  网络中的链路容量和交换结点中的缓存和处理机都有着工作的极限，当网络的需求超过它们的工作极限时，就出现了拥塞。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。常用的方法就是：
  1、慢开始、拥塞控制；
  2、快重传、快恢复；
  一切的基础还是慢开始，这种方法的思路是这样的：
  1）、发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口；
  2）、当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文；
  3）、当收到第一个字节的数据的确认后，就发送2个字节的报文；
  4）、若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级；
  5）、最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定：
  *1、cwnd < ssthresh，继续使用慢开始算法；
  *2、cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法；
  *3、cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法；
  6）、所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长；
  7）、当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）；

  上述方法的目的是在拥塞发生时循序减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。慢开始和拥塞控制算法常常作为一个整体使用，而快重传和快恢复则是为了减少因为拥塞导致的数据包丢失带来的重传时间，从而避免传递无用的数据到网络。快重传的机制是：
  1）、接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求；
  2）、一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包；
  3）、此时发送方开始执行“快恢复”算法：
  *1、慢开始门限减半；
  *2、cwnd设为慢开始门限减半后的数值；
  *3、执行拥塞避免算法（高起点，线性增长）；

  TCP 滑动窗口协议，窗口过大或过小有什么影响？
  滑动窗口的大小对网络性能有很大的影响。
  如果滑动窗口过小，极端的情况就是停止等待协议，发一个报文等一个 ACK，会造成通信效率下降。
  如果滑动窗口过大，网络容易拥塞，容易造成接收端的缓存不够而溢出，容易产生丢包现象，则需要多次发送重复的数据，耗费了网络带宽。  

72、TCP与UDP的对比

  TCP、UDP 都是传输层协议，他们的通信机制与应用场景不同。
  TCP（Transmission Control Protocol），又叫传输控制协议，UDP（User Datagram Protocol），又叫用户数据报协议，它们都是传输层的协议，但两者的机制不同，它们的区别如下：

  TCP的优点：可靠，稳定。TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。TCP的缺点：慢，效率低，占用系统资源高，易被攻击。TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。而且，因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。
  UDP的优点：快，比TCP稍安全。UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击……；UDP的缺点：不可靠，不稳定，因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。
  基于上面的优缺点，那么： 什么时候应该使用TCP： 当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。在日常生活中，常见使用TCP协议的应用如下： 浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输…………；什么时候应该使用UDP：当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。 比如，日常生活中，常见使用UDP协议的应用如下：QQ语音、QQ视频、TFTP ……。
  TCP与UDP区别总结：
  1、TCP面向连接（如打电话要先拨号建立连接）；UDP是无连接的，即发送数据之前不需要建立连接；
  2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP尽最大努力交付，即不保证可靠交付；
  3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流；UDP是面向报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）；
  4、每一条TCP连接只能是点到点的；UDP支持一对一，一对多，多对一和多对多的交互通信；
  5、TCP首部开销20字节；UDP的首部开销小，只有8个字节；
  6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道；

72.1、可靠性补充

  在通信的角度来看，可靠即要确保通信双方的通信信息不会丢失，若丢失了保证能够对其进行恢复，并且收到的信息内容与原发送内容一样。
  在 TCP 中，传输报文都是通过建立的虚拟连接来进行传输，发送端传输的每一个 TCP报文，都会对其进行编号（编号是由于网络传输的原因，发送的报文可能会乱序到达，因此需要根据编号对报文进行重排），并且开启一个计时器；当接收端收到报文后，并且通过校验和对收到的报文数据进行校验，若校验成功则会返回一个确认报文，告知发送端我已经成功收到该报文了；若发送端在计时器结束前仍未收到确认报文，则认为接收端接收失败，则会重传该报文；服务端若收到重复报文（根据编号发现已经是收到了），则会将该报文丢弃。
  UDP不需要确保服务端一定能收到或收到完整的数据。它仅仅提供了校验和机制来保障一个报文是否完整，若校验失败，则直接丢弃报文，不做任何处理。
  基于TCP协议的应用层协议：http、ftp、telnet、smtp；
  基于UDP协议的应用层协议：dns、rip、tftp；