你真的会TCP与UDP？

一、TCP

1.1TCP特点

• TCP是面向连接的传输层协议，应用层协议是用tcp协议前必须建立连接，数据传输完毕需要释放tcp连接。
• TCP值能是点对点通讯
• TCP提供可靠的交付服务：数据五差错、不丢失、不重复并且按序到达
• TCP提供的全双工通信，TCP允许成序任何时候发送数据，TCP连接的两端都设置有发送缓存和接收缓存，在发送时，应用程序在把数据传送给TCP的缓存后，就可以做自己的事，而TCP在合适的时候把数据发送出去。在接收时，TCP把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
• TCP面向字节流：
  

面向字节流的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义。TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系（例如，发送方应用程序交给发送方的TCP共10个数据块，但接收方的TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序）。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。当然，接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。

1.2 TCP报文段和首部格式

我们先看看TCP报文进出协议栈时前后封装了些什么


源/目端口号：应用进程与应用进程之间通信的监听出入口。
序列号：序列号随机生成，每次序号都会不一样，ISN算法随机生成。序列号会随着双方通讯而不断的增加。序列号一共32比特，最大值2^32-1，到达最大值后重新从0开始。

随机生成算法：ISN = M + F(localhost, localport, remotehost, remoteport).
M是一个计时器，这个计时器每隔4毫秒加1。
F是一个Hash算法，根据源IP、目的IP、源端口、目的端口生成一个随机数值。要保证hash算法不能被外部轻易推算得出，用MD5算法是一个比较好的选择。

确认序列号：确认序列号是上次已成功接收到数据字节序列号加1。ack=seq+1
首部长度：选项不用，TCP的头部为20字节；存在选项则为60字节。
保留：为将来定义新的用途保留，现在一般置0。
标志：每个标志占1比特，1表示有效，0为无效。

• URG：紧急指针是否有效。有效会告诉系统此时有紧急数据需要尽快传送。
• ACK：确认序号是否有效。仅当ACK=1时确认字段才有效。建立连接后，所有的传送的报文都必须把ACK置为1。
• PSH：推送 ，接收方应该尽快将这个报文段交给应用层。不必等待缓存区满后再向上交付
• RST：复位，对方要求重新建立连接。当RST=1代表TCP连接出现严重差错，必须释放连接再重新建立连接。
• SYN：同步序列号，请求建立连接。在连接请求中，SYN=1 ACK=0表示该数据段是未捎带确认的连接请求报文；SYN=1 ACK=1表示是一个捎带了确认的连接请求报文。
• FIN：用于释放连接，FIN=1时表示发送方已经没有数据发送了，即关闭本方数据流。
  **窗口：**滑动窗口大小，用来告知发送端接受端的缓存大小，以此控制发送端发送数据的速率，从而达到流量控制。窗口大小最大为65535（ 2^16 -1 ）。
  **检验和：**发送端基于数据内容计算一个数值，接收端要与发送端数值结果完全一样，才能证明数据的有效性。接收端checksum校验失败的时候会直接丢掉这个数据包。CheckSum是根据伪头+TCP头+TCP数据三部分进行计算的。另外对于大的数据包，checksum并不能可靠的反应比特错误，应用层应该再添加自己的校验方式。
  紧急指针： 16位，指向后面是优先数据的字节，在URG标志设置为1时才有效。如果URG标志没有被设置，紧急域作为填充。加快处理标示为紧急的数据段。
  选项：长度不定，但长度必须以是32bits的整数倍,最长可以达到40字节。常见的选项包括MSS、SACK、Timestamp等等，
  **数据：**可选，在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段、

1.3TCP的建立和终止

1.3.1正常三次握手

注：TCP三次握手，可能是四次，如双方同时主动请求连接

1.3.2 四次挥手

1.3.3 为什么连接只需要三次握手，断开需要四次？

• 这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方是否现在关闭发送数据通道，需要上层应用来决定，因此，己方ACK和FIN一般都会分开发送。

1.3.4 三次握手存在什么问题？怎么解决

问题：
三次握手会存在syn flood攻击：最基本的DoS攻击就是利用合理的服务请求来占用过多的服务资源，从而使合法用户无法得到服务的响应。syn flood属于Dos攻击的一种。
如果恶意的向某个服务器端口发送大量的SYN包，则可以使服务器打开大量的半开连接，分配TCB（Transmission Control Block）, 从而消耗大量的服务器资源，同时也使得正常的连接请求无法被相应。当开放了一个TCP端口后，该端口就处于Listening状态，不停地监视发到该端口的Syn报文，一 旦接收到Client发来的Syn报文，就需要为该请求分配一个TCB，通常一个TCB至少需要280个字节，在某些操作系统中TCB甚至需要1300个字节，并返回一个SYN ACK命令，立即转为SYN-RECEIVED即半开连接状态。系统会为此耗尽资源
防御措施：

• 无效连接的监视释放：视系统的半开连接和不活动连接，当达到一定阈值时拆除这些连接，从而释放系统资源。这种方法对于所有的连接一视同仁，而且由于SYN Flood造成的半开连接数量很大，正常连接请求也被淹没在其中被这种方式误释放掉，因此这种方法属于入门级的SYN Flood方法。
• 延迟TCB分配：消耗服务器资源主要是因为当SYN数据报文一到达，系统立即分配TCB，从而占用了资源。而SYN Flood由于很难建立起正常连接，因此，当正常连接建立起来后再分配TCB则可以有效地减轻服务器资源的消耗。常见的方法是使用Syn Cache和Syn Cookie技术。
• Syn Cache技术：系统在收到一个SYN报文时，在一个专用HASH表中保存这种半连接信息，直到收到正确的回应ACK报文再分配TCB。这个开销远小于TCB的开销。当然还需要保存序列号。
• Syn Cookie技术 ：Syn Cookie技术则完全不使用任何存储资源，这种方法比较巧妙，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS(Maximum Segment Size，最大报文段大小，指的是TCP报文的最大数据报长度，其中不包括TCP首部长度。)、时间等，在收到对方的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源。
• syn代理：SYN Proxy防火墙，防火墙确定连接有效性后防火墙才会向内部服务器发起SYN请求。防火墙代服务器发出的SYN ACK包使用的序列号为c, 而真正的服务器回应的序列号为c’, 这样，在每个数据报文经过防火墙的时候进行序列号的修改。另一种方式是防火墙确定了连接的安全后，会发出一个safe reset命令，client会进行重新连接，这时出现的syn报文会直接放行。这样不需要修改序列号了。但是，client需要发起两次握手过程，因此建立连接的时间将会延长。

1.3.5 MSL与2MSL等待时间

• TCP报文的在网络上单向传送的最大生存时间叫做MSL

• 2MSL（最大报文段生存时间）等待状态。之所以要等待，是因为关闭方要确认处于“CLOSE_WAIT”状态的被关闭方收到它最后的ACK报文，，等待确认报文来回的时间就是2MSL，如果被关闭方在2MSL内都没有收到ACK，就会重复发送FIN报文。如果关闭方在2MSL时间内未收到被关闭方的报文，则默认收到
  Windows : MSL = 2 min
  linux(Ubuntu, CentOs) : MSL = 60s

• 2MLS等待原因

  • 2MSL的时间能保证在两个传输方向上的未被接收的数据和迟到的数据全部被丢弃（当连接关闭时，有可能收到迟到的报文段。这时，若立马就建立新的连接（同一端口），那么新的连接就会接收迟到的报文，误以为是发给自己的）
    -保证了最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了,但是TCP连接还在,仍然可以重发LAST_ACK）如果直到2MSL，客户端都没有再次收到FIN，那么客户端推断ACK已经被成功接收，则结束TCP连接。

1.4 可靠传输实现机制

1.4.1 通过序列号与确认应答提高可靠性

• TCP数据传输是以段为单位发送数据，每一段数据都有序列号，实现数据的排序、
• TCP通过肯定的确认应答（ACK）实现可靠的数据传输。当发送端将数据发出之后会等待对端的确认应答。如果有确认应答，说明数据已经成功到达对端。反之，则数据丢失的可能性很大。

1.4.2 重发超时如何确定

• 数据被重发后若还没收到确认应答，则进行再次发送，等待确认应答时间会以2倍、4倍指数延长。
  

1.5 TCP传输控制

1.5.1 利用窗口控制提高效率

将窗口分等级，一次简历

1.5.2 流控

流控：TCP提供以中机制可以让发送段根据接收端的接收能力控制发送数据包数量

1.5.3 拥塞控制

• TCP的通信开始时间。并没有设置慢启动阀值，而是在重传时才会设置（设置为拥塞窗口的一半大小）
• 上图是一个简单的示意图，下面饿哦们介绍一个用色窗口一行设置了的启动流程
  

1.5.4 提高网络利用率的规范

• Nagle算法：点击查看
• 延迟确认应答：避免因为刚接收数据缓冲区变小而早成，窗口的大小调小。
• 捎带应答：是TCP包中既发包有确认的一种应答机制，提高网络利用率
  

1.6TCP中的四种计时器

• **重传计时器：**在数据发送完成后开始计时，如果在规定的时间内没有收到ACK就会重传。
• **坚持计时器：**在拥塞控制的时候使用，当接收端通知发送端窗口大小为0后，发送端会停止发送数据，但是当接收端有足够缓存之后，会重新通知新的窗口大小给发送端，如果新窗口大小的报文丢失了，就会进入一个死循环，为了应对这种情况，当发送端收到窗口大小为0的通知之后，会启动坚持计时器，到设定时间后会向接收端发送探测报文，该报文中只有一个字节的数据，他有序号，但是这个序号永远不需要确认，探测报文的目的是提醒发送端，新发送的窗口大小丢失。发送之后会将该计时器的值设为原来的两倍，直到到阀值（一般为60s），然后每隔60S就会发送一个探测报文，知道接收到新窗口的确认报文为止。
• 保活计时器：建立TCP连接后，客户端故障，tcp连接闲置，服务端设置保活计时器后，在超过计时器设定时间就会终止连接
• 时间等待计时器：在连接终止时，会设置一个时间等待计时器，就是time_wait状态时的计时器，该计时器可以接受重复的Fin报文到达目的站，从而将其丢弃（时间设置一般为报文的期待时间的2倍）

二、UDP

2.1 UDP特点

• UDP是无连接的，减小了开销和发送数据前的时延（相对TCP而言）
• UDP采用最大努力交付，主机不需要维护复杂的连接状态；
• UDP是面向报文的，只在应用层交下来的报文前增加了首部后就向下交付IP层；
• UDP是无阻塞控制的，即使网络中存在阻塞，也不会影响发送端的发送频率
• UDP支持一对一、一对多、多对一、多对多的交互通信
• UDP的首部开销小，只有8个字节，它比TCP的20个字节的首部要短。

2.2 UDP报文结构

2.2常见应用：

• 包总量较少的通信（DNS、SNMP等）
• 视频、音频等多媒体通信（即时通信）
• 限定于LAN等特定网络中的应用通信
• 广播通信（广播、多播）