本文是看王道和计算机网络微课堂所写，不过关于三次握手，四次挥手推荐大家看这篇文章，写得比较详细 https://www.cnblogs.com/biehongli/p/11964057.html

传输层的初步认识

传输层概述

传输层是只有主机才有的层次

在五层体系中，传输层可以为应用层提供通信服务，也可以使用网络层的服务。
接下来看看传输层的功能:
①传输层提供进程和进程之间的逻辑通信(网络层提供的是主机之间的逻辑通信)
②复用和分用
举个生活中的例子来说明一下复用和分用。
比如说你们家有好多人同时都想要写信给你们的朋友，你们可以把信放在家门口的信箱，邮局会派人把信收集起来，收集完后，会派发出去，这就类似于复用
接下来说明一下分用
当各自写的信都收到了回复，信都 会放在门口的信箱中，然后我们取出来，分发给具体的每一个人，这就类似于分用
③传输层对收到的报文进行差错检测
④传输层的两种协议:TCP(可靠传输),UDP(不可靠传输)

传输层的两个协议

• 面向连接的传输控制协议TCP
  • 传送数据之前必须建立连接，数据传送结束要释放连接
  • 不提供广播或多播服务
  • TCP提高可靠的面向连接的传输服务，所以增加了许多开销:确认，流量控制，计时器连接管理等
  • 可靠，面向连接，时延大，适合用于大文件
• 无连接的用户数据报协议UDP
  • 传输数据前不需要建立连接
  • 收到UDP报文后也不需要发送任何的确认
  • 不可靠，无连接，时延小，适合用于小文件

传输层的寻址与端口

先来回顾一下传输层的复用和分用这两个功能
复用:应用层所有的应用进程都可以通过传输层再传输到网络层
分用:传输层从网络层收到数据后交付发指明的应用进程
怎么指明应用进程呢？
在网络层和链路层，对于一个主机来说，我们如果想要发送信息给它，只需要网络地址和IP地址，找到对应的网络后，我们就得根据它对应MAC地址定位到具体哪一个主机，找到主机后，我们还得找到是这台主机的哪一个进程，这就涉及到传输层的问题,端口

端口(软件端口，是看不见摸不着的)是传输层的SAP，标识主机中的应用进程

端口号只有本地意义，它是为了标识本计算机应用层中的各个进程，在因特网中不同计算机的相同端口是没用联系的
端口号长度为16bit,能表示65535个不同的端口号

IP数据报首部中协议字段的值，表名了IP数据报数据载荷部分封装的是何种数据单元

UDP

用户数据报协议UDP概述

• UDP只在IP数据报服务之上增加了很少功能，即复用分用和差错检测功能
• UDP主要特点
  • UDP是无连接的，减少开销和发送数据之前的时延
  • UDP使用最大努力交付，即补保证可靠交付
  • UDP是面向报文的，适合一次性传输少量数据的网络应用
  • 
  • UDP无拥塞控制，适合很多实时应用
  • UDP首部开销小，8字节
  • TCP首部开销20字节

UDP首部格式

17就是IP数据报首部的协议字段
在UDP伪首部中，包含32位源IP地址，32位目的IP地址，8位协议，16位UDP长度。通过伪首部的校验，UDP可以确定该数据报是不是发给本机的，通过首部协议字段，UDP可以确认有没有误传。

UDP校验

TCP

TCP协议的特点

• TCP是面向连接(虚连接)的传输层协议 类似于打电话
• 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的
• TCP提供可靠交付的服务，使得报文无差错，不丢失，不重复，按序到达
• TCP提供全双工通信
  • TCP协议的两端都会设置有发送缓存和接收缓存
    • 发送缓存
      • 可以看成准备发送的队列
      • 发送缓存包含准备发送的数据和已经发送但是还没有接收到确认的数据
    • 接收缓存
      • 可以看成准备发送的队列
      • 接收缓存包含按序到达但是还没有被接收应用程序读取的数据，以及不按许到达的数据
• TCP是面向字节流的
  • TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流
  • 流:流入到进程或从进程流出的字节序列

TCP报文段首部格式

TCP连接管理

• TCP传输的三个阶段:连接建立，数据传送，连接释放 类似于打电话
• TCP连接的建立采用的是客户服务器方式，主动发起建立的应用进程叫做客户，被动等待连接建立的应用进程叫做服务器
• 

TCP的连接建立

TCP连接释放

参与一条TCP连接的两个进程中的任何一个都鞥终止该连接，连接结束后，主机中的资源(缓存和变量)将被释放

TCP可靠传输

在上面的图片中，左边是发送方，右边是接收方，发送方有多个报文段，首先发送方发送第一个报文段给接收方，也就是1，2，3字节构成的报文段，发过去以后，接收方就收到了，并且把它存储在自己的TCP缓存当中，并且寻找一个合适的时机把缓存中的报文段提交到上层，提交给应用层。
此时发送方的TCP缓存当中仍然有1，2，3字节构成的报文段，因为报文在发送过程可能出现丢失的情况，就导致接收方接收不到发送方发送的报文段，接收方就会要求发送方重传。因为接收方为了保证可靠传输，就必须保证发送方发送的信息它都能按序完整的接收到.所以这个报文段要在发送方的缓存中一直存在，直到接收方告诉发送方，它已经完整收到了，这样，发送方才可以把这个报文从缓存中删除。

那么发送方怎么样才能知道接收方完整而且正确的接收到呢?这就需要依靠我们的确认机制

接收方接收到报文段后，就会返回一个确认报文段，这个报文段是在合适的时候进行确认，我们一般是采用累积确认的方式，接收方在合适的时候发送一个只是起到确认作用的报文段。有的时候，接收方也可以在自己有信息发送的时候，把确认信息捎带上，也就是捎带确认

假设接收方发送的是一个只有确认功能的报文段
确认字段就是期待收到的下一个字节，刚刚接收方已经接收到1，2，3字节组成的报文段，那么接下来它就希望收到的是4字节开始的报文段

当发送方接收到了确认字段，就知道接收到已经接收到了自己刚刚发送的报文段，此时，它就可以把刚刚发送的报文段从自己的TCP缓存中删除

接下来，发送方就可以继续发送后面的报文段，比如发送4，5，6的报文段和7，8的报文段，可能因为网络的原因，此时，接收到只有接收到7，8组成的报文段

为了实现可靠传输，接收方会使用累计确认的方法

发送方接收到了确认报文后，就知道要重传4号报文段

TCP重传
确认重传不分家，TCP的发送方在规定时间(重传时间)内没有收到确认就要重传已经发送的报文段，这叫超时重传.
TCP的下层是互连网的环境，发送的报文段可能只经过一个高速率的局域网，也有可能是经过多个低速率的网络，每一个IP数据报选择的路由也是不一样的，取决于当时的网络，这就导致对于一个发送方来说，它发送的很多报文段走的路径不一样，经过的时间也不一样。
如果重传时间设置很短，就会导致很多报文不必要的重传
如果重传时间设置很长，会导致网络空闲的时间很长，减少传输效率。

TCP采用自适应算法，动态改变重传时间RTTs(加权平均往返时间)

TCP流量控制

这个时候，主机A不能发送报文给B，直到主机B重鑫发送一个新的窗口值，也就是B主机在接收缓存腾出位置，把缓存的一些数据上交给上层的应用层后，才可以继续接收数据，这个时候主机B给主机A发送一个接收窗口为400的报文段，但是这个报文段在发送的过程丢失了，A就会一直处于等待的状态，等待B可以发送一个让它可以继续发送数据的通知，B也一直在等待，等待A给它发送数据，因为B已经发送了通知，如果没有其他的措施的话，主机A和主机B就会一直等待，类似于操作系统的死锁。接下来看看采取什么方法解决这个问题

TCP拥塞控制

传输轮次是指发送方给接收方发送数据报文段后，接收方给发送方发回想应的确认报文段，一个传输轮次经历的时间其实就是往返时间(不是固定数值)

在TCP双方建立逻辑连接关系时，拥塞窗口的值被设置为1，传输轮次为0的拥塞窗口为1，此外，我们还得设置慢开始门限的初始值，假设为16。
在执行慢开始算法的时候，发送方每收到一个对新报文段的确认时，就把拥塞窗口值加1，然后开始下一轮的传输。
当拥塞窗口值增加到慢开始门限值时，就改为执行拥塞避免算法。由于发送方当前拥塞窗口值是1，而发送窗口值等于拥塞窗口值，所以发送方当前只能发送一个TCP数据报文段。换句话说，拥塞窗口是几，就能发送几个数据报文段




发送方收到后，把拥塞窗口中修改为16，此时，发送方的拥塞窗口值已经增大到了慢开始门限值，之后，我们要改用拥塞避免算法，也就是每个传输轮次结束后，拥塞窗口值只能线性加1，而不像慢开始算法那样，每个传输轮次结束后，拥塞窗口值按照指数规律增大


中间的过程类似，不再一一演示

由于部分报文段丢失，这就会导致超时重传

• 慢开始和拥塞避免算法是1998年提出的TCP拥塞控制算法(TCP Tahoe版本)
• 1990年又增加了两个新的拥塞控制算法(改进TCP的性能),这就是快重传和快恢复(TCP Reno版本)

•