传输层提供的服务

• 地位
  

• 概述

进程 端口号 传输层协议之间的关系

socket套接字

• 解决了每次传输 需要重复输入协议（TCP/UDP）以及对方的IP地址和端口号的问题 它的本质是一种数据结构
• 例如进程1与进程5之间需要传输数据 因为他们都是使用的TCP协议 所以就会创建一个TCP套接字
• 在这个套接字里面需要指明对方的IP地址和端口号
• 接下来如果两个进程之间需要有多次的数据传输 就可以直接用套接字来说明传输方向

有链接 VS 无连接 | 可靠 VS 不可靠

• 在下面两张图中 左边指的是TCP 右边指的是UDP
  

UDP数据报及检验

• UDP
  
• TCP
  

数据报格式

检验方法

• 对于一组数据
  
• 对于多组数据
  
• 说明
  
• 小节
  

TCP

TCP协议的三大阶段

• 一次链接可以传输多个报文
  

• 这里引入了换一个概念就是MSS 表示我们传输时报文段的最大长度

• 这里重点说一下这句话“TCP是面向字节流的 UDP是面向报文的”

• 怎么样来理解呢

• 对于TCP协议而言 它将应用层交给他的数据看作是一连串的字节流 不管关心数据到底是报文Y的还是报文Z的 只是根据MSS的限制将它拆分成合适的大小进行传输

• 跟前面UDP不同的是 UDP数据报每次运输的都是一个完整的报文

• 这便是 面向字节流和面向报文的含义

TCP报文段格式（很重要）

建立连接（三次握手）（超级超级重要）

• 因为我们的TCP协议是在建立连接的基础之上的 所以我们在传输数据之前必须有一个建立连接的过程
• 在前面的学习中我们知道当SYN=1的时候 表示这是一个连接请求或者接受报文 对应到下图中显然只有握手1是在请求连接 只有握手2是在同意请求连接
• 则显然只有握手1和握手2的SYN=1
• seq表示传输的数据的起始位置 ack=667 说明的是我（接收方）希望你下一次给我发送的数据是从667开始的
• 这里还需要提一下窗口值的概念
• 例如A发送给B的时候设置window=200 ack=100意思是告诉B 你下一次给我发送数据的时候要从100这个位置开始 并且的接收能力是200 换句话说 从100开始 我（A）还允许你给我发200B的数据
  
• 特别要注意的是 对于握手2 他虽然表示的同意连接 也就是他的TCP报文段只由首部构成 并没有任何的数据部分 但是他仍然需要消耗一个序号 即他返回的ack需要在seq（起始位置）的基础上+1
• 为什么说需要特别注意呢 因为握手3可以选择要不要携带数据 他在不带数据的情况下跟握手2不同的是 他并不需要消耗一个序号
  
• 三次握手的状态变化

数据传输

释放连接（四次挥手）

• 在前面我们学习了FIN=1表示发送方的数据已经全部发送完毕
• 但是我们的TCP是提供全双工通信的 也就是双向的 这是一个传输层的协议
• 不同于我们数据链路层实现流量控制与可靠传输时候学习的S-W，GBN，SR等协议 他们都是有明确的发送方和接受方的 也就说明他们是工作在半双工条件下的协议
• 在四次挥手中只有挥手1（表示客户传输完毕）和挥手3（表示服务器传输完毕）表示数据传输完毕 也就是说他们是都可以作为发送方的
• 挥手2和挥手4是我们各自作为接收方告诉对面数据已经被接收 而这恰恰又体现了TCP是一种可靠 有连接的传输服务
• 特别需要说明的是挥手1和挥手3可以携带数据 但是他们一般不携带数据
• 而挥手2是可以携带数据的 因为挥手1仅仅是进程A单方面结束了数据传送
• 挥手4是不可以携带数据的 因为挥手3之后已经代表数据传送结束了
  #### 四次挥手的状态变化
• 对于TIME-WAIT这个状态是用于我们防止我们的服务器没有接收到挥手4 假如真的传输失败了
• 那么这个时间段的等待就是非常有必要的 因为对于我们的服务器而言 他长时间没有收到我们A给他发送的挥手4
• 他就会重新发送挥手3 这样我们的进程A就会收到 然后重新发送挥手4
• 如果这一段时间什么也没有收到 那么我们的客户进程就默认对面已经收到了我们发出的挥手4

TCP连接管理小节

TCP流量控制和可靠传输

• 首先TCP是一个传输层概念 他实现流量控制和可靠传输的方式和我们数据链路层是非常类似的
• 可靠传输方面 它跟我们数据链路层一样 用到这个确认机制 不过来这里我们这个是对于报文段的一个确认 可以接受一个报文段就返回一个ACK
• 在重传机制方面 也是非常类似 就是只要在规定时间之内没有收到接受方返回的ACK那么就需要重发
• 举个例子 对于四次挥手 我们的发送方是在最后需要CLOSE阶段之前 也就是我们发送方收到挥手3之后设置一个TIME-WAIT阶段
• 这个阶段的时长是2倍MSl 表示我们报文段在网络中存在的最大寿命 设置的本质原因就是 我们的需要发送方他需要确保服务器收到了我们的请求关闭数据传送的信息 也就是我们需要收到挥手4才能进入CLOSE阶段
• 假设我们服务器返回的这个ACK丢失了 那么在过了一段时间时候 客户端进程就会重新发送 直到顺利接收服务器返回的ACK
• 在流量控制方面 也是类似 引入滑动窗口机制 这个时候接收方和发送方都会维持一个窗口 根据传输过程中发送的 rwnd的值来告诉对方 从某个序号开始 我最多还能接受多少数据
  

可靠传输-拥塞控制

TCP 拥塞控制和流量控制的关系

• 之前学习的流量控制的对象是两个进程各自的某个端口 也就是局部的控制
• 拥塞控制实现的是控制整个网络的数据发送量 是全局的
  

慢开始 与拥塞控制算法

• 首先我们在建立TCP连接之后 就会默认使用慢开始算法 也就是说一开始的发送窗口的值为1 之后每隔一个RTT（往返时延）我们的发送窗口就会翻倍 也就是x2按指数级增长 直到达到阈值（ssthresh）
• 这里唯一需要注意的一点是 如果在阈值前一个RTT 照理来说他是需要翻倍的 但是如果发送窗口此时翻倍之后 超过了这个阈值 那么取其中的较小值作为发送窗口的大小 也就是min{阈值 cwnd}
• 之后的时间内 会自动转为拥塞避免算法 就好比之前我们刚刚开始运动 每天的运动量都翻倍 但是随着运动量越来越大 我们肯定需要降低他的增长速度 也就对应了这里的拥塞避免算法 使得增长速度降为线性
• 通过之前的学习我们知道一旦出现了超时重传 可能说明我们网络当中某些路由器的负载太大了 以至于不能及时返回确认信息 所以此时认为严重拥塞 那么此时会干两件事情
• 1. 在这个RTT结束之后我们检测到拥塞 立即将cwnd（拥塞窗口）设置为1
• 2.阈值设置为原来的一半 本质上就是降低数据的发送量
• 之后延续之前的流程 一开始还是使用慢开始 到达阈值之后使用拥塞避免算法
  
• 例题
• 对于在解决这道例题之前 我们需要明确的是 之前在拥塞控制那里玩吗讨论的前提是接收窗口足够大 导致玩吗每次调整发送窗口大小完全是依据拥塞窗口来调整的
• 但实际情况是 发送窗口=min{rwnd,cwnd}
• 此外还需要注意的是一般来说都会设置MSS=1KB这个条件 也就是说 我们阈值和发送/接收缓冲区的大小就是他们的值除以1KB
• 好那知道这些之后我们再去看这道例题

• 首先 我们的阈值是32 乙的接收窗口rwnd大小是16 说了乙是将数据全部存入缓存 不被取走 也就说说暂时还不交付给应用层
• 其次基本思路就是我们甲他的发送窗口不能大于乙的接收窗口rwnd 同时不能大于他的拥塞窗口
• 0时刻 阈值S=32 r=16 c=1 发送窗口：1
• 1时刻 S=32 r=15 c=2 发送窗口：2
• 2时刻。 S=32 r=13 c=4 发送窗口：4
• 3时刻。 S=32 r=9 c=8 发送窗口：8
• 4时刻。 S=32. r=1 c=16 发送窗口：1

结语

今天翻草稿箱的时候 居然还有以前写的文章没发出去哈哈 还有好几篇等我稍微完善一下再发出去
该说不说 现在感觉ipad写还行啊 感觉CSDN优化了～