计算机网络-运输层（UDP/TCP协议）

---

前言

上一篇我们简介了应用层，介绍了在应用层两个重要的协议DNS和HTTP，在这篇，我们来认识运输层，这给层有两个非常重要的协议UDP和TCP，其中TCP更是这层的大哥，是不是突然发现计算机网络非常有趣，一层一层的了解，每层都有大BOSS。话不多说，开始吧！

一、计算机网络

还是每篇都出现的这张图吧！这张图可谓是开启计算机网络的秘钥，也能让你有一个总体的框架，

二、运输层

• 概括
  运输层是为了向他的上面一层的应用层提供通信服务的。两台主机通信其实就是两台主机中的应用进程互相通信，网络层的IP协议虽然能把分组送到目的主机，但是这个分组还是停留在主机的网络层，还没有进入到应用进程中。通信的真正端点并不是主机是主机中的应用进程。
  网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端对端的逻辑通信。

1、复用和分用

复用

• 应用层的所有应用进程都是通过运输层再传达到网络层的。
  分用
• 运输层从网络层拿到数据后，必需分别交付给对应的应用进程

在这里有一点，就是如何对应把数据交给对应的应用进程，所以在这里还有个关键的协议端口号

• 服务器端用
  • 系统端口 ：一些重要的应用程序说使用的（0-1023），https：443 ， http：80 ，dns：53
  • 登记端口：给没有熟知端口的应用程序使用的（1024-49151），必须登记防止重复
• 客户端用
  • 短暂端口：客户程序在运行的过程动态选择，包含在请求中，告诉应该接收的端口，进程结束会释放端口。

2、UDP

定义

• UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。UDP 是User Datagram Protocol的简称， 中文名是用户数据报协议，是OSI（Open System Interconnection，开放式系统互联） 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务
• 相比IP报并没有多大的变化，只是在ip数据报的基础上添加了一个UDP首部，用来实现复分和分用功能的。

特点

• 无连接，每次发送数据前都是直接发送的，好处，减少连接的开支，和低时延

• 面向报文的，在UDP报文只是简单的加上UDP首部，进入到网络层，在到达目的主机的应用层后，只需要去掉UDP首部就能使用了

• 不可靠，UDP是一个不可靠的传递，不会保证数据的完整，会出现误包和丢包问题，接收方也是只管接收的。他没有过多的控制协议，但同时也因此，在数据传输过程中延迟小、数据传输效率高，适合对可靠性要求不高的应用程序

• 支持一对一，一对多，多对一，多对多：多播，广播，单播

• 首部开销小，只要添加八个字节的就可以了。

所以因为这些特点，UDP常用在网络直播，视频会议等，而不是应用在对可靠性要求比较高的地方。

首部格式

• 源端口：需要对方回信时用，不需要就全为0
• 目的端口：终点交付报文用的
• 长度：UDP用户数据报的长度，最少为i8
• 检验和：检测在传输中有没有错

注意点

3、TCP

定义
好家伙，这玩意是为了解决UDP的许多问题的，所以他是一种面向对象，可靠性，基于字节流的运输层协议

特点

• 有连接 ：会通过三次握手和四次挥手来建立连接和断开，只有建立连接才能传输，结束要断开连接。
• 面向字节：TCP 会将发送方的数据块仅仅看作一连串无结构的字节流，TCP不知道字节流的含义和顺序，所以接收方必需能识别收到的字节流并且还原为有意义的应用层数据。
• 传输单位为数据段：虽然面向字节流，但传输的单位是数据段，并且大小不固定的。
• 只支持一对一（端对端，单播传输）：每一条TCP连接都有两个端点，这个端点也叫套字节或插口
• 提供可靠服务：无差错，不丢失，不重复，有序到达
• 全双工通信发送时，应用程序吧数据发送给TCP的缓存后，就能干自己的事了，TCP根据自己的发送策略，在合适的时候，加上首部构建成 TCP 报文段进行发送。最后接收方的 TCP 一方面将 TCP 报文中提取出数据并存储在缓存，接收方的应用进程在合适的时候提取出来。

首部格式

• 一个TCP报文段分为首部和数据两部分。下图为首部的构成。首部长度可变，最短为20+4n字节，
  
• 源端口和目的端口：源端口和目的端口分别代表呼叫方和被叫方的TCP端口号，一个端口与IP地址就可以完整地构成套接字（Socket）
• 序号：指TCP数据段中的“数据”部分的第一个字节的编号。例如某个数据段的序号是123，这个数据段共有100个字节，那么这段数据报的最后一个字节的编号是222，，下一个数据段的序号应该是223.
• 确认号：确认号指期望接收到对方下一个数据段中“数据”部分的第一个字节序号。例如主机B已收到主机A发来的一个数据段，其序号值是101，而该数据段的长度是100字节。这表明主机B已收到主机A前200个字节，下一个期望要收到的数据段的第一个字节的序号应该是201，于是主机B在给主机A发送确认数据段时要把“确认号”设置为201
• 数据偏移：指出TCP报文段的首部长度。因为首部的长度是不确定的。
• 还有太多了，自己查吧~~~~

Ⅰ- TCP的灵魂拷问 - TCP 和 UDP 的区别

1. 有无连接
   UDP 协议在进行在发送数据之前，是可以随机发送数据，而不需要进行连接。但是如果通过 TCP 协议进行通信的话，那么它们首先要通过“三次握手”进行连接，连接之后才可以发送数据，最后还需要使用“四次挥手”释放连接。
2. 通信方式
   UDP 支持单播、多播和广播的方式， 而 TCP 仅支持单播。
3. 对应用层报文的处理
   收到应用层报文，UDP 会直接给应用层报文添加一个首部，使之成为应用层用户数据报，然后进行发送。接收方 UDP 接收到该报文以后，只需将首部去掉，然后将报文交付给接收方的应用进程就行了。我们看到，UDP 不会对报文进行拆分，因此它是面向报文的。也就是基于数据包
   TCP 则会将发送方的数据块仅仅看作一连串无结构的字节流，将它们编号并存储在缓存中，然后根据自己的发送策略，提取一定量的字节，加上首部构建成 TCP 报文段进行发送。最后接收方的 TCP 一方面将 TCP 报文中提取出数据并存储在缓存，另一方面将接收缓存中的一些字节交付给接收方的应用进程。也就是基于字节流
4. 是否可靠
   UDP是尽可能交付就可以了，不保证可靠性。
   TCP具有可靠性保证、通过滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制，使用校验和，确认和重传机制来保证可靠传输

Ⅱ - TCP的灵魂拷问 - 三次握手

三次握手发生在 TCP连接建立的时期，三次握手也就是服务器和客户端之间发送交换三次 TCP报文。

那么为什么是需要三次呢？

我们先来了解建立 TCP连接的建立。下面是一个小的对话，而 TCP连接的建立也是类似的。

张三：李四你在吗？
李四：张三我在家。
张三：好的，我知道你在家了。

如图：

先说一下途中的每一个字段含义：
SYN：连接请求/接收 报文段
seq：发送的第一个字节的序号
ACK：确认报文段
ack：确认号。希望收到的下一个数据的第一个字节的序号

过程：

1. 首先是客户端主动打开连接的，而服务端时被动打开连接，并且服务器进程转到 LISTEN （收听）状态，等待客户端请求。
2. 接着客户端发送请求报文，首部的同步位 SYN = 1， 同时选择一个初始序号 seq = x（取值范围为=1234567），这时客户端进程进入到 SYN-SENT（同步已发送）状态，等待服务端回应。注意，这个过程不能发送数据。
3. 服务端收到数据包后由标志位 SYN = 1知道客户端请求建立连接，服务端将标志位 SYN 和 ACK 都置为1，ack = x+1，随机产生一个值 seq = y，并将该数据包发送给客户端A以确认连接请求，服务端B进入 SYN_RCVD（同步已收到）状态。注意，这个过程也不能发送数据。
4. 客户端收到确认后需要给服务端回复，先检查 ack 是否为 x+1，ACK是否为1，如果正确则将标志位 ACK 置为1，ack = y+1，并将该数据包发送给服务端。这个过程可以发送数据了。
5. 服务端检查 ack 是否为 y+1，ACK是否为1，如果正确则连接建立成功，客户端和服务端进入ESTABLISHED（已建立连接）状态，完成三次握手，随后客户端A与服务端B之间可以开始传输数据了。

这里就完成我们的 TCP创建连接了。但是好像还没明白为什么要三次呀？两次不行吗？四次不行吗？为什么是三次呢？

问题区

1.为什么是三次，不是两次是四次呢？

首先三次握手是为了避免这三个问题的：
1. 三次握⼿才可以阻⽌重复历史连接的初始化(主因)
2. 三次握⼿才可以同步双⽅的初始序列号
3. 三次握⼿才可以避免资源浪费

解释：

1.阻⽌重复历史连接的初始化(主因)
我们先看为什么能避免第一个问题，这是因为客户端发送的请求可能会因为某些原因丢失或者滞留了，导致这个本来已经失效的连接请求突然又传到服务端，而服务端收到后就想客户端发送确认请求，同意建立连接，那么如果是两次握手的话，这时候就建立了新的连接，但因为客户端现在并没有发送请求，所以不会理睬服务器，但服务器却以为新的连接建立了，一直傻傻的等，这不就非常的浪费服务端的资源。
两次握⼿在收到服务端的响应后开始发⽣数据，不能判断当前连接是否是历史连接。
三次握⼿可以在客户端准备发送第三次报⽂时，客户端因有⾜够的上下⽂来判断当前连接是否是历史连接。
三次握手的话，当旧的请求报文到达服务端后，服务端会返回一个确认报文，客户端收到后，可以根据自身判断这个是一个历史连接（超时或过期），客户端就会发送一个 RST报文给服务端，表示终止这一个连接。
客户端判断是否为历史连接是根据 seq 和服务端返回的 ack。

2. 同步双⽅的初始序列号
TCP 协议的通信双⽅， 都必须维护⼀个「序列号」， 序列号是可靠传输的⼀个关键因素。

• 接收端可以去除重复数据。
• 接收端可以按照序列号顺序接收。
• 标识发送的数据包，哪些已经被收到。
  过程

1. 客户端发送第⼀个报⽂A，携带客户端初始序列号的SYN报⽂，其中 seq = x。
2. 服务器回复第⼆个报⽂B，服务器的应答报⽂中有 ack = x+1 以及 seq = y，表示收到客户端的SYN报⽂。
3. 客户端发送第三个报⽂C，这里客户端通过服务端的报文中 ack = x+1， 可以确保服务端收到自己发送的上一个报文A，同时回复服务端的报文中 ack = y +1 也能使得服务端知道自己收到报文B。

这样确保了双⽅的初始序列号能被可靠的同步。
两次握⼿只保证了⼀⽅的初始序列号能被对⽅成功接收，没办法保证双⽅的初始序列号都能被确认接收。也就是只能确保服务端收到报文A，无法确保报文B是否被客户端收到

3.避免浪费资源

1. 两次握手当发生历史连接会浪费服务端资源
2. 当客户端的请求发生丢失，客户端没有收到服务端的回应会重新发送请求报文
3. 因为服务端不确认客户端是否收到自己的确认报文，所以每收到一个请求报文就会创建一个确认连接

2、什么是SYN 洪泛攻击

解释：

SYN 洪泛攻击就是用客户端在短时间内伪造大量不存在的 IP地址，并向服务端疯狂发送SYN。
正常情况下，我们在三次握手过程，客户端发送 SYN报文到服务端，而服务端收到后回复SYN-ACK报文到客户端，而客户端回复ACK报文。服务端收到后完成三次握手，TCP连接建立。
但是实际上黑客攻击会伪造大量不存在的客户端 IP 不断的发送 SYN报文，而服务端收到SYN报文后，会回复SYN-ACK报文，同时在连接超时前，会一直等待 ACK报文。但是并不会等到伪造客户端的ACK报文，导致服务端大量连接处于SYN_RCVD状态，占满整个半连接队列，占用服务器的连接数，而当连接数超出时，服务器就无法正常提供服务了，处理正常的请求了。而且由于是不存在的 IP ，服务端收不到回复，还会一直不断的重发数据，直到耗尽服务端资源~
解决方法：
1.SYN cookie： 我们可以对在发送的SYN-ACK报文中添加一个特定的cookie，让客户端返回的ACK报文中加上这个，那么我们在收到这个值的时候就可以把这个ip加入到白名单（伪造的不会回复ACK报文的）
2.增加半连接队列的值
3.过滤网关防护

ps：其实三次握手并不是发生了三次握手，而是一次握手过程交换了三个报文~~为什么叫三次握手是翻译的问题，就沿用广为流传的了

Ⅲ - TCP的灵魂拷问 - 四次挥手

四次挥手发生在 TCP连接释放中

方便查看，这里在先说一下途中的每一个字段含义：
FIN ：连接终止位
seq：发送的第一个字节的序号
ACK：确认报文段
ack：确认号。希望收到的下一个数据的第一个字节的序号
过程：

1. 首先客户端发送一个 FIN报文，其中把 FIN = 1 并且设置 seq = u ，告诉服务器需要关闭连接，表示自己不再发送数据了，主动关闭TCP连接，但是要注意，此时客户端还能接收数据（之前服务端还没发完的），客户端进入 FIN_WAIT1 （ 终止等待 1）状态，等待服务端的确认。
2. 服务端收到后，会马上发送 ACK 报文， 设置 ack = u + 1 ， ACK = 1 并且设置 seq = v ， 表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT （关闭等待）状态，客户端进入到 FIN_WAIT2 （ 终止等待 2）的状态。所以这个阶段是 客户端到服务端的连接断了，但是 服务端到 客户端的没有断 ，服务端要是继续发送数据客户端还是需要接收，但是服务端不会收到来自客户端的数据了。会维持到服务端发送完全部数据。
3. 当服务端发送完全部数据就会发送释放报文 FIN+ACK报文， 其中 FIN = 1 ， seq = w ，ack = u + 1 。告诉客户端准备关闭了。这时服务端进入 LAST_ACK（最后确认） 的状态，等待客户端的确认。
4. 客户端收到后，再发送ACK报文，其中 ACK= 1 ， seq = u+1 ，ack = w + 1 。进入TIME_WAIT（时间等待）状态，等待服务端可能请求重传的ACK包。服务端接收到ACK包后，关闭连接，进入CLOSED状态。这时服务端到客户端的连接还没有断的，要等 2MSL 后客户端才会进入到CLOSED

问题区

1 、为什么需要等待2MSL时间

这个是有两个原因的。

• 一个是为了确保客户端的最后一个 ACK报文能被服务端接收到
• 其次是防止历史连接的出现

解释：

1.确保客户端的最后一个 ACK报文能被服务端接收到
这个报文可能会发生丢失，那么服务端收不到自己发送的 FIN+ACK报文的确认 ，就会超时重传这个 FIN+ACK报文。而客户端就能在 2MSL 中收到这个报文，并且重传一次确认，这样大家都能进入到 CLOSED 状态。要是客户daunt发送完就关了，当服务端发送重传的 FIN+ACK报文级不能被客户端接收到了，服务端就无法进入到 CLOSED状态。

2. 防止历史连接的出现
因为 2MSL后 这个时间是本次连接持续时间内产生的所有报文都会在网络中消失。这样可以确保不会有历史连接的出现

2、为什么需要四次握手

解释

1.为什么需要四次
因为 TCP的半关闭（half-close）特性，TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
客户端发送 FIN报文 ，表示自身不再发送数据，但是还能接收数据，所以服务端收到 FIN报文，会先回复一个 ACK报文，接着可能还需要处理和发送数据，不再需要发送的时候才发送 FIN报文来告诉客户端关闭。

Ⅳ - TCP的灵魂拷问 - TCP如何实现可靠传输

TCP确保可靠传输有好几个方面组成，通过这些手段保证了，数据的可靠交付。
1、滑动窗口

2、超时重传和确认到达

3、流量控制

4、拥塞控制

总结

提示：这里对文章进行总结：
例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。