图解传输层 TCP UDP

传输层的功能

从通信和信息处理的角度看，传输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。

网络层：ip协议的作用范围，提供主机之间的逻辑通信

TCP和UDP协议的作用范围（提供进程之间的逻辑通信），同时还对接受到的包报文经行差错检测，运输层提供面向连接和无连接的服务。

UDP和TCP协议

用户数据报协议UDP

• UDP传送的协议数据单元是UDP报文或用户数据包

• UDP在传送数据之前不需要先建立连接。对方的运输层在收到UDP报文后，不需要给出任何确认。显然UDP不提供可靠的交付，但是某些情况下UDP是一种有效的工作方式。

• UDP是无连接的，即发送数据之前不需要建立连接。

• UDP使用尽最大努力交付，不保证可靠交付，同时也不是用拥塞控制

• UDP是面向报文的。UDP没有拥塞控制，很适合多媒体通信的要求

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

• UDP的首部开销小，只有8个字节。

• UDP无状态连接，TCP需要在端系统中维护连接状态，连接状态包括接收和发送缓冲，拥塞控制参数以及序号和确认号的参数，在UDP中没有这些参数，也没有发送缓存和接受缓存。因此，某些专门用于某种特定应用的服务器当应用程序运行在UDP上，一般能支持更多的活跃用户。

• 这里需要注意一点，并不是所有使用UDP协议的应用层都是不可靠的,应用程序可以自己实现可靠的数据传输，并通过确认和重传机制。所以使用UDP协议最大的特点就是速度快

• UDP不可靠的原因它虽然提供差错检测的功能，但是对差错没有恢复能力更加不会有重传机制。
  

传输控制协议TCP

• TCP传输的数据单元是TCP报文段。
• TCP是面向连接的运输层协议。
• 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的，TCP连接的端点不是主机，不是主机的IP地址，不是应用进程，也不是传输层的协议端口，TCP连接的端点叫做套接字（端口号拼接到IP地址构成了套接字）。
• TCP提供可靠交互的服务,有丢失重传机制，下面会简述，TCP提供全双工通信，面向字节流。
• TCP提供面向连接的服务。由于TCP要提供可靠的，面向连接的运输服务，如丢失重传，流量控制，拥塞重传,因此会不可避免的增加很多开销，这不仅会让数据单元的首部增加很多，还要占用很多处理机资源。
• TCP的端口，端口用一个16位端口号进行标志。端口号只具有本地意义。即端口号只是为了标志计算机中应用层中的各进程。在因特网中不同计算机的相同端口号是没有联系的。
• TCP只能进行点对点连接，也就是所谓的多播，即一个主机对多个接收方发送消息的情况是不存在的，TCP连接只能连接两个一对主机。

TCP可靠通信的实现

可靠传输的工作原理---- 停止等待协议

在发送完一个分组后，必须暂时保留已经发送的分组的副本，分组和确认分组都必须经行编号，超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

使用上述的确认和重传机制，就可以在不可靠的传输网络上实现可靠传输了。这种可靠传输协议被称为自动重传请求ARQ（Automatic Repeat reQuest）。

ARQ表明重传是自动经行的，接收方不需要请求放发送方重传某个出错的分组。

这种停止的等待优点是简单，但是确定是信道利用率太低。所以出现了连续ARQ协议。

接收方一般采用累计确认的方式。

优点是：容易实现，即使确认丢失也不必重传
缺点是：不能向发送方反应出接收方已经正确收到所有分组的信息。

TCP报文段的首部格式

源端口和目的端口字段——各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。

序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。
确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。
数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）。
紧急 URG —— 当 URG =1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数，不用在发送窗口排序
确认 ACK —— 只有当 ACK = 1 时确认号字段才有效。当 ACK = 0 时，确认号无效。
推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。
复位 RST (ReSeT) —— 当 RST =1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。

同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。
终止 FIN (FINish) —— 用来释放一个连接。FIN =1表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。
窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。
检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首

紧急指针字段 —— 占 16 位，指出在本报文段中紧急数据共有多少个字节，只有URG=1时才有效。
选项字段 —— 长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”
填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。

滑动窗口协议

下面给出以字节为单位的滑动窗口

发送缓存用来暂时存放

1. 发送应用程序传送给发送方 TCP 准备发送的数据；
2. TCP 已发送出但尚未收到确认的数据。
   

接收缓存用来暂时存放

1. 按序到达的、但尚未被接收应用程序读取的数据
2. 不按序到达的数据。

有关以字节为单位的滑动窗口技术 需要强调三点：

1. A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）。

2. TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

3. TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销。

TCP的流量控制机制

流量控制(flow control)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。

利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。流量控制(flow control)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。

利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。

只要 TCP 连接的一方收到对方的零窗口通知，TCP 就启动持续计时器。零窗口推测报文段仅携带 1 字节的数据，接收方就在确认这个零窗口探测报文段时给出了现在的窗口值（接收窗口值）。若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。若窗口不是零，则死锁的僵局就可以打破了。

TCP的拥塞控制

在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏——产生拥塞(congestion)。出现资源拥塞的条件：
对资源需求的总和 > 可用资源

拥塞控制是指发送方先设置一个小的窗口值作为发送速率，当成功发包并接收到ACK时，便以指数速率增大发送窗口的大小，直到遇到丢包（超时/三个冗余ACK），才停止并调整窗口的大小。这么做能最大限度地利用带宽，又不至于让网络环境变得太过拥挤。

• 若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。

• 拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。

• 拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

• 流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制。

• 流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制是很难设计的，因为它是一个动态的（而不是静态的）问题。
当前网络正朝着高速化的方向发展，这很容易出现缓存不够大而造成分组的丢失。但分组的丢失是网络发生拥塞的征兆而不是原因。在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化甚至发生死锁的原因。

发送方维持一个叫做拥塞窗口 cwnd (congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。如再考虑到接收方的接收能力，则发送窗口还可能小于拥塞窗口。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。 只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
最终滑动窗口的值将设置为接受窗口（流量控制窗口）和拥塞控制窗口中的最小值。

---

满开始和拥塞避免

慢开始:在主机开始发送报文段时可先设置拥塞窗口cwnd=1，每经过一个传输轮次，拥塞窗口cwnd就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。

例如，拥塞窗口 cwnd = 4，这时的往返时间 RTT 就是发送方连续发送 4 个报文段，并收到这 4 个报文段的确认，总共经历的时间。

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

什么时候使用慢开始，什么时候使用拥塞避免算法?

慢开始门限ssthresh的用法如下:

• 当cwnd<ssthresh时，使用满开始算法
• 当cwnd>ssthresh时，停止使用满开始算法而改用拥塞避免算法
• 当cwnd=ssthresh时，即可使用满开始算法，也可使用拥塞避免算法

当网络出现拥塞时

• 无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有按时收到确认），就要把慢开始门限 ssthresh 设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。
• 然后把拥塞窗口 cwnd 重新设置为 1，执行慢开始算法。
• 这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
  
  “乘法减小“是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5。当网络频繁出现拥塞时，ssthresh 值就下降得很快，以大大减少注入到网络中的分组数。

拥塞避免并不是完全能够避免拥塞，只是让网络比较不容易出现拥塞

---

快重传和快恢复

---

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认。这样做可以让发送方及早知道有报文段没有到达接收方。

当发送端收到连续三个重复的确认时，就执行“乘法减小”算法，把慢开始门限 ssthresh 减半，但拥塞窗口 cwnd 现在不设置为 1，而是设置为慢开始门限 ssthresh 减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

TCP UDP区别总结

	TCP	UDP
连接性	面向连接	不建立连接
传输可靠性	可靠	不可靠
报文	面向字节流	面向报文
效率	传输效率比udp底	传输效率比tcp搞
流量控制	滑动窗口	无
拥塞控制	慢开始，避免拥塞，快重传，快恢复	无
传输速度	较udp慢	较tcp快
应用场合	对效率要求低，对准确性要求高或要求有连接的场景	对效率要求高，可以些许掉包

三次握手

• 首先，客户端首先向服务器发送一个特殊的TCP报文段.这个报文段不包含数据，将首部的SYN标志位置为1。客户端随机选择一个初始序号，并将此数字放入初始TCP SYN段的序列号字段中

• 一旦包含IP数据段到达服务器后，服务端后提取出其中的报文段，将TCP缓冲区和变量分配给连接。

  这些缓冲区和变量的分配使TCP容易受到SYN泛洪攻击

• 第一次握手(SYN=1,seq=x)
  此时，客户端进入SYN-SENT（同步发送状态）。TCP规定，SYN报文段(SYN=1)不能携带数据，但需要消耗一个序号。
  

• 第二次握手(SYN=1,ACK=1,seq=y,ACKnum=x+1)
  服务器进入SYN-RCVD（同步收到）状态。这个报文不能携带数据，但是同样要消耗一个序号。

• 第三次握手(ACK=1,ack序号为y+1)
  客户端收到服务器的SYN+
  
  在客户端主机和服务端主机建立连接后，参与一条 TCP 连接的两个进程中的任何一个都能终止 TCP 连接。连接结束后，主机中的缓存和变量将会被释放。
  

• LISTEN: 表示等待任何来自远程 TCP 和端口的连接请求。

• SYN-SEND: 表示发送连接请求后等待匹配的连接请求。

• SYN-RECEIVED: 表示已接收并发送连接请求后等待连接确认，也就是 TCP 三次握手中第二步后服务端的状态

• ESTABLISHED: 表示已经连接已经建立，可以将应用数据发送给其他主机

为什么TCP建立连接的过程需要3次握手过程，两次不是就能保住连接是连通的吗？

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。为了保证每个连接的有效性，避免服务器资源浪费。

具体例子：“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接

SYN超时，洪泛攻击，以及解决策略

什么是SYN泛 洪攻击？在TCP的三次握手机制中的第一步中，客户端会向服务器发送SYN报文段。服务器收到SYN报文端后会为该TCP分配缓存和变量，如果大量的向服务发送SYN报文段，服务器的连接资源将被耗尽,导致内存溢出无法继续服务。

解决策略:当服务器接受SYN报文段时，不直接为该TCP分配资源，而只打开一个半开的套接字。使用SYN报文段的源ID,目的id,端口号以及有服务器自己知道的一个秘密函数生成一个序列号a，并且把序列号a响应给客户端。

如果客户端是正常连接，会放回a+1的确认号。服务器根据源ID,目的id,端口号以及有服务器自己知道的一个秘密函数生成一个序列号，如果序列号+1等于确认字段的值，就证明是刚刚请求连接的客户端，这时候为该tcp分配资源，这样一来就不会为恶意攻击的 SYN 报文段分配资源空间，避免了攻击。。

四次挥手

TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，也叫做改进的三次握手。客户端或服务器均可主动发起挥手动作。

• 第一次挥手(FIN=1,seq=u)
  客户1进入FIN_WAIT_1状态；
  
• 第二次挥手(ACK=1,ack=u+1)
  客户A进入FIN_WAIT_2状态；服务器告客户，我“同意”你的关闭请求；服务端进入CLOSE_WAIT状态
  
• 第三次挥手(FIN=1,seq=w)
  服务器进入LAST_ACK状态
  
• 第四次挥手(ACk=1,acknum=w+1)
  客户端向服务器发送ACK报文段，然后客户端进入TIME_WAIT状态；服务器收到客户的ACK报文以后，就关闭连接；此时客户机等待2MSL后依然没有收到回复，则证明Server端已正常，客户端就可以关闭连接了，进入CLODED状态。

• 连接状态
  
  为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
  第一，为了保证 A 发送的最后一个 ACK 报文段能够到达 B。
  第二，防止 “已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

务器出现了大量CLOSE_WAIT状态如何解决

大量 CLOSE_WAIT 表示程序出现了问题，对方的 socket 已经关闭连接，而我方忙于读或写没有及时关闭连接，需要检查代码，特别是释放资源的代码，或者是处理请求的线程配置。

TCP协议如何来保证传输的可靠性

• 数据包校验:目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
• 应答机制
• 超时重传:当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
• 流量控制

TCP 可靠通信的具体实现
TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。
TCP 的可靠传输机制用字节的序号进行控制。
TCP 两端的四个窗口经常处于动态变化之中。
TCP连接的往返时间 RTT 也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。

在浏览器中输入一个 URL（www.demo.com/home.html） 至页面呈现，网络上都发生了什么事？

• DNS服务器首先会经行域名映射，找到比如URL对应的ip地址，然后http客户端进程在80端口发起一个到服务器的TCP连接（默认端口是80）。在客户和服务器进程中都会有一个套接字和其相连。（3次握手）
• HTTP客户端通过它的套接字向服务器发送一个http请求报文。该报文中包含了路径/home.index的资源。
• http服务器通过它的套接字接受该报文，经行请求解析工作，并从其 存储器(RAM或磁盘)中检索出/home.html的资源，然后把检索出来的对象经行封装，封装到http响应报文中，并通过套接字向客户端经行发送
• http服务器随即通知tcp断开tcp连接，实际上是需要等到客户接受完响应报文后才会断开tcp连接。（四次握手）
• http客户端接受完响应报文后，tcp连接会关闭。http客户端从响应中提取报文中是一个html响应文件，，并检查该 HTML 文件，然后循环检查报文中其他内部对象，http客户端会把对应的资源通过显示器呈现给用户。