TCP协议与UDP协议

1.TCP协议特点

1.1连接的建立与断开

        TCP协议提供的是：面向连接、可靠的、字节流服务。使用TCP协议通信的双发必须先建立连接，然后才能开始数据的读写。双方都必须为该连接分配必要的内核资源，以管理连接的状态和连接上数据的传输。TCP连接是全双工的，双方的数据可以通过一个连接进行读写。完成数据交换之后，通信双方都必须断开连接以释放系统资源。

       三次握手发生在客服端执行connect()的时候，该方法返回成功，则说明三次握手已经建立。三次握手示例图如下：

四次挥手发生在客户端或服务器端执行close()关闭的时候，示例图如下：

 

SYN标志:请求建立一个连接，我们称携带SYN标志的TCP报文段为同步报文段。

ACK标志:表示确认号是否有效。我们称携带ACK标志的TCP报文段为确认报文段

FIN标志:表示通知对方本端要关闭连接了。我们称携带FIN标志的TCP报文段为结束报文段。

思考题：

1.为什么是三次握手，可不可以是两次为什么？

三次握手的步骤：

第一次握手：客户端向服务器端发送 SYN和序列号（如seq=i）。

第二次握手：服务器端向客户端发送SYN和序列号(seq=j)和ACK确认号(i+1)。

第三次握手：客户端向服务器端发送ACK确认号(j+1)。

之所以是三次握手，是因为只有双方都收到自己的seq被对方确认，才会认为这条连接时可靠的。如果只是两次握手，那么至多只有连接发起方的起始序列号能被确认，另一方的序列号得不到确认。换句说，如果是两次握手建立连接，第二次握手时发送丢包，那么客户端就无法与服务器建立连接。

2.如果监听队列listen(sockfd,5)大小是5，是不是服务器只能连接五个客户端？

不是，虽然listen()监听队列大小是5，表示能存放已完成三次握手连接的长度是5，但是accept()会从监听队列中接收已完成三次握手的连接，所以监听队列大小是5，不代表服务器端只能连接五个客户端。

3.三次握手过程中客户端向服务器端发送的SYN和序列号是不是，调用send()发送过去的？

 不是，客户端代码中connect()开始三次握手，connect()结束三次握手完成，三次握手未完成客户端和服务器端连接还未完成，用户不能发数据，所以SYN和序列号不是用户发送的，是传输层协议发送的。

4.四次挥手可不可以是三次呢？

四次挥手的步骤：

(1).先调用close()的一端向另一端发送FIN和序列号

(2).另一端向先调用close()的一端发送ACK确认号进行确认

(3).另一端调用cloe()向先调用close()的一端发送FIN和序列号

(4).先调用close()的一端向另一端发送ACK确认号进行确认。

四次挥手可以是三次挥手，当先调用close()的一端向另一端发送FIN和序列号时，另一端也刚好close()，此时另一端会把FIN和序列号和确认号ACK一起发送给先调用close()的一端。此时就是三次挥手。

发送缓冲区和接收缓冲区

 5.三次握手时可能出现什么攻击

一、握手阶段消息丢失

二、握手阶段队列已满

1.2TCP状态转移

        TCP 连接的任意一端在任一时刻都处于某种状态，当前状态可以通过 netstat 命令查看，下图是 TCP 连接从建立到关闭整个过程中通信两端状态的变化。其中 CLOSED 是假想的起始点，并不是一个实际的状态。

 上图中TIME_WAIT状态一般是主动关闭的一端才会出现的状态。该状态出现后，会维持一端长为2MSL(Maximum Segment Life)的时间，才会完全关闭。MSL是TCP报文段在网络中的最大生存时间。

TIME_WAIT状态存在的原因有两点：

可靠的终止TCP连接。

保证让迟来的TCP报文有足够的时间被识别并丢弃。

        在Linux系统上，一个TCP端口不能被同时打开多次，（两次及以上）。当一个TCP连接处于TIME_WAIT状态时，我们将无法立即使用该连接占用着的端口来建立一个新的连接。

思考题：

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

可以，因为TCP和UDP是不同的协议。

1.3流式服务特点

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

思考问题：

什么是粘包，如何解决？

      tcp协议是面向连接的，客户端和服务器是连接的，所以不同的send()发送的数据在同一个发送缓冲区中，即发送方发送的若干包数据到接收方接收时粘成一包，从接受缓冲区来看后一包的数据紧接着前一包数据的尾。

        如理方法：发送端send()一个一个发送

1.4应答确认与超时重传

        TCP 发送的报文段是交给 IP 层传送的。但 IP 层只能提供尽最大努力的服务，也就是
说， TCP 下面的网络所提供的是不可靠的传输。因此， TCP 必须采用适当的措施才能使两个运输层之间的通信变得可靠。 TCP 的可靠传输是通过使用应答确认和超时重传来完成。
下图是通过 netstat 命令抓包看到的信息：

 下图是无差错时， 数据交互的流程： 发送端发送数据 m1 给接收端，接收端收到数据后
会给发送端一个确认信息，以表明数据已经被成功收到。在发送方未收到确认信息前， M1
应继续被保留，直到确认信息到达才能丢弃

 下图是出现差错时，数据交互的流程：

1.5滑动窗口

         TCP 协议是利用滑动窗口实现流量控制的。一般来说，我们总是希望数据传输得更快一些，不会一次只发一个字节。但是如果发送方把数据发得过快，接受方就可能来不及接收，这就会造成数据的丢失。 所谓流量控制就是让发送方的发送速率不要太快，要让接收方来的及接收。

        在 TCP 的报头中有一个字段叫做接收通告窗口，这个字段由接收端填充，是接收端告
诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力
来发送数据，而不会导致接收端处理不过来。所以发送端就会有一个发送窗口，这个发送窗
口的大小是由接收端填充的接收通告窗口的大小决定的，并且窗口的位置会随着发送端数剧的发送和接收到接收端对数据的确认而不断的向右滑动，将之称为滑动窗口。
发送方的滑动窗口示意图如下：

 当收到 36 的 ack，并发出 46-51 的字节后，窗口滑动的示意图如下：

1.6拥塞控制

         在计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资
源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性
能就要变坏。这种情况就叫做拥塞。 所谓拥塞控制就是防止过多的数据注入到网络中，这样
可以使网络中的路由器或链路不致过载。拥塞控制是一个全局性的过程，涉及到所有主机，
所有路由器，以及与降低网络传输性能有关的所有因素

几种拥塞控制的方法：
慢开始、拥塞避免、快速重传、快速恢复

慢开始、拥塞避免、快速恢复示意图：

 快速重传示意图：

2.UDP协议的特点

        UDP数据报服务的特点：发送端应用程序每执行一次写操作，UDP模块就将其封装成一个UDP数据报发送。接收端必须及时针对每一个UDP数据报执行读操作，否则就会丢包。并且，如果用户没有指定足够的应用程序缓冲区来读取UDP数据，则UDP数据会被截断。