1. 计算机网络_运输层
在IP层看来，通信的两端是两个主机，IP数据报的首部明确的标志了这两个主机的IP地址。但是两个主机之间的通信这种说法还不够清楚，这是因为真正进行通信的实体是在主机中的 进程 ，是两个进程之间在交换数据。从而引出了运输层，从运输层的角度看来， 通信的真正端点并不是主机而是主机中的进程 （端到端的通信）。
在一个主机中经常有多个应用进程同时分别和另一个主机的多个应用进程通信。这就表明了运输层有一个很重要的功能， 复用和分用 ，应前亩配用层不同进程的报文通过不同的端口向下交到运输层，再往下就共用网络层提供的服务。
“运输层提供应用进程间的逻辑通信”。“逻辑通信”的意思是：运输层之间的通信好像是沿水平方向传送数据。但事实上这两个运输层之间并没有一条水平方向的物理连接。
TCP/IP 的运输层有两个不同的协议：
由此可见两个计算机中的进程要相互通信，不仅要知道对方的IP地址，还要知道对方的端口号。
如果接收方UDP发现收到的报文中的目的端口号不正确（即不存在对应于该端口的号的应耐戚用进程），就丢弃该报文，并由网际控制报文协议ICMP发送 端口不可达 差错报文给发送方。
在计算检验和时，临时把 “伪首部” 和 UDP 用户数据报连接在一起得到一个临时的数据报，它不向下传递也不向上递交。 伪首部仅仅是为了计算检验和 。
UDP计算检验和的方法和IP数据报首部检验和方法相类似。但不同的是，IP数据报的检验和 只检验IP数据报的首部 ，但UDP的检验和是 把首部和数据部分一起检验
计算UDP检验和的例子：
在发送方，先把全0放入检验和字段，再把伪首部以及UDP用户数据报看成是许多16位的字串接起来。若UDP用户报的数据部分不是慧指偶数个字节，则要填入一个全零字节（先不发送）。然后按照 二进制反码 计算出这些16位字的和。将此和的二进制反码写入 检验和字段 后，就发送这样的UDP数据报。在接收方，把收到的UDP数据报连通伪首部（以及可能填充全零字节）一起，按二进制反码求这些16位字的和。当无差错时其结果应为全1（原本的检验和为0，封装成数据报后再次相加的时候就多个检验和反码相加，所以无差错时结果为1）。
每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定，即：
TCP发送的报文段是交给IP层传输的。但IP层只提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠传输，因此，TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。
在这样的理想传输条件下，不需要采取任何措施就能够实现可靠传输。然而实际的网络都不具备以上两个理想的条件。但我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当的降低发送数据的速度，这样一来，本来是不可靠的传输信道就能够实现可靠传输。
停止等待协议的优点是简单，但缺点是 信道利用率 太低。
假定AB之间有一条直通的信道来传送分组
这里的TD是A发送分组所需要的时间（显然TD = 分组长度 / 数据速率）再假定TA是B发送确认分组所需要的时间（A和B处理分组的时间都忽略不计）那么A在经过TD+RTT+TA时间后才能发送下一个分组，这里的RTT是往返时间，因为只有TD是采用来传输有用的数据（这个数据包括了分组首部，如果可以知道传输更精确的数据的时间，可以计算的更精确），所有信道利用率为
为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用 流水线传输 ：就是发送方可以 连续的发送多个分组 ，不必每发完一个分组就停下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然这种传输方式可以获得很高的信道利用率
当时使用流水线传输时，就要使用下面介绍的 连续ARQ协议 和 滑动窗口协议
滑动窗口协议比较复杂，是TCP协议的精髓所在，在这里先给出ARQ协议最基本的概念，但不涉及到许多细节问题。
位于发送窗口的分组都可以连续的发送出去，而不需要等待对方的确认，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
详细可以见P201
TCP虽然是面向字节流的，但是TCP传送的数据单元却是报文段（可以看上述TCP面向流的概念），而且TCP的 全部功能都体现在它的首部中各个字段 。
详解请见P206，注意图中的后沿，前沿
从下图可以看出来，要描述一个发送窗口的状态需要三个指针：P1，P2，P3
有很多信息见P208，这里不赘述
发送方的应用进程把字节流写入TCP的发送缓存，接收方的应用进程从TCP的接收缓存中读取字节流。下面进一步讨论前面讲的 窗口和缓存 的关系
发送缓存
发送窗口通常只是发送缓存的一部分，已被确认的数据应当从发送缓存中删除，因此 发送缓存和发送窗口的后沿是重合 的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中被写入的字节。发送应用程序必须控制写入缓存的速率，不能太快 ，否则发送缓存就会没有存放数据的空间。
如果收到的分组被检测出有差错，则要丢弃。如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减少到零。反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收缓存的大小。
TCP才用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。
TCP 保留了 RTT 的一个 加权平均往返时间 RTTs （这又称为平滑（smooth）的往返时间，因为是加权平均，所以是平滑的）。
第一次测量到 RTT 样本时， RTTS 值就取为所测量到的 RTT 样本值 。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS：
显然，RTO 应略大于上面得出的加权平均往返时间 RTTs
RFC 2988 建议使用下式计算 RTO：
RTTD 是 RTT 的 偏差的 加权平均值，他与RTTs和新的RTT样本之差有关。
RFC 2988 建议这样计算 RTTD。第一次测量时，RTTD 值取为测量到的 RTT 样本值的一半。在以后的测量中，则使用下式计算加权平均的 RTTD：
β是个小于 1 的系数，其推荐值是 1/4，即 0.25。
为了解决上面那个问题，Karn提出了一个算法
在计算平均往返时间 RTT 时，只要**报文段重传了，就不采用其往返时间样本。这样得出的加权平均平均往返时间 RTTS 和超时重传时间 RTO 就较准确。 **
但是，这又有了新的问题、设想出现这样的情况：报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。
报文段每重传一次，就把 RTO 增大一些：
系数 γ 的典型值是 2 。
当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延 RTT 和超时重传时间 RTO 的数值。
实践证明，这种策略较为合理。
接收方收到了和前面的字节流 不连续 *的两个字节块（只是未按序号，它是无差错的）
如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。
和前后字节不连续的每一个字节块都有两个边界：左边界和右边界。图中用四个指针标记这些边界。第一个字节块的左边界 L1 = 1501，但右边界 R1 = 3001。左边界指出字节块的第一个字节的序号，但右边界减 1 才是字节块中的最后一个序号。第二个字节块的左边界 L2 = 3501，而右边界 R2 = 4501。
详见P211
一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，
接收方就可能来不及接收，这就会造成数据的丢失。
流量控制(flow control)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞 。
利用 滑动窗口机制 可以很方便地在 TCP 连接上实现流量控制。
A 向 B 发送数据。在连接建立时，�B 告诉 A：“我的接收窗口 rwnd = 400（字节）”。 看下TCP首部窗口字段的用处
接收方的主机B一共进行了3次流量控制（蓝线）
考虑一种情况，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd = 400的报文段，然而这个报文段在传输过程中丢失了。A一直等收到B发送非零窗口的通知，B也一直等A发送数据来，就形成了 死锁 。下面的 持续计时器 就是为了打破死锁僵局的
应用进程把数据传送到TCP发送缓存后，剩下的发送任务就由TCP来控制了。可以用不同的机制来控制 TCP 报文段的发送时机:
至于如何控制发送的 时机 详见P213
在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏——产生 拥塞(congestion)
出现资源拥塞的条件： 对资源需求的 总和 > 可用资源
若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。
解决拥塞的要点是 平衡 ，要让整个系统的性能想匹配（P214）。
横坐标为 提供的负载 ，代表单位时间内输入给网络的分组的数目（也叫作输入负载或网络负载），纵坐标是 吞吐量 ，代表单位时间内从网络输出的分组数目。
由于缺少缓存空间而被丢弃的分组的百分数，平均队列长度，超时重传的分组数，平均分组时延，分组时延的标准差等，这些指标的上升都标志着拥塞的增长。
方便起见，我们用 报文段的个数 作为窗口大小的单位
慢开始门限 ssthresh 的用法如下：
拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增长 ，比慢开始算法的拥塞窗口增长速率缓慢很多。
网络出现拥塞时
当 TCP 连接进行初始化时，将拥塞窗口置为 1。图中的窗口单位不使用字节而使用 报文段 。
慢开始门限的初始值设置为 16 个报文段，即 ssthresh = 16。
发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。
下面的执行步骤就是按照折现上的点的顺序
2. 【网络】TCP/IP-传输层知识概要
首先确定下传输层的作用
例子：
．在OSI参考模型中，自下而上第一个提供端到端服务的层次是 传输层
解析
传输层，传输层的是作用是负责为两台主机中应用进程之间的通信提供服务，而对于网络层来说，提供的是主机到主机之间的通信，所谓的端到端是指应用进程到应用进程。
SYN（synchronous）是TCP/IP建立连接时使用的握手信号。在客户机和服务器之间建立正常的TCP网络连接时，客户机首先发出一个SYN消息，服务器使用SYN+ACK应答表示接收到了这个消息，最后客户机再以ACK消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。
在第一次发送信息中，A随机选取一个序列号x作为初始化序列号发送给B。
第二次B使用ack对A的数据报进行确认，因为已经收到了序列号为x的数据包，准备接收序列号为x+1的包，所以ack=x+1,同时发送自己的初始化序列号seq=y
TCP连接的第一个包，非常小的一种数据包。SYN 攻击包括大量此类的包，由于这些包看上去来自实际不存在的站点，因此无法有效进行处理。每个机器的欺骗包都要花几秒钟进行尝试方可放弃提供正常响应。
如下图所示，IP 地址在IP 数据报的首部，而硬件地址则放在MAC 帧的首部。在网络层以上使用的是IP 地址，而链路层及以下使用的是硬件地址。
TCP的连接端点称为 套接字（socket），根据TCP协议的规定，端口号拼接到IP地址即构成了套接字。
也就是说TCP连接的端点不是主机，不是IP不是应用进程，而是套接字。
套接字 socket = （IP地址：端口号）
套接字 socket = (IP地址: 端口号)
TCP 连接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}
Socket连接是一个五元组，包括协议类型，源IP，源端口，目标地址和目标端口
TCP是面向字节流的，每一个字节对应一个序列号。
TCP每次发送的报文段的首部中的序列号是该报文枯世段的第一个字节的序号。
接收端返回的确认号是收到数据的最高序号加1
一个 TCP报文段的数据部分最多是
IP数据报 的最大长度=2^16-1=65535（字节）
TCP报文段的数据部分= IP数据报 的最大长度- IP数据报 的首部-TCP报文段的首部=65535-20-20=65495（字节）
在IP 层抽象的互连网上，我们看到的只是IP 数据报，路由器根据目的站的 IP地址进行选路。在具体的物理网络的链路层，我们看到的只是 MAC 帧，IP 数据报被封装在 MAC帧里面。
MAC 帧在不同的网络上传送时，其MAC 帧的首部是不同的。这种变化，在上面的IP 层上是看不到的。每个路由器都有IP 地址和硬件地址。使用IP 地址与硬件地址，尽管连接在一起的网络的硬件地址体系各不相同，但 IP层抽象的互连网却屏蔽了下层这些很复杂的细节，并使我们能够使用统一的、抽象的IP 地址进行通信。
当某个路由器发现一数据报的检验和有差错时，会直接丢弃。
思考
如何理解TCP/IP 协议本是为非实时数据业务而设计的
例：为什么在 TCP 首部中有一个首部长度没羡肢字段，而 UDP 的首部中就没有这个字段？
答：这是TCP 与UDP 包的区别，TCP 包的首部字段可以更好的保证数据传输的可靠安全，而UDP 就不能保证，所以UDP 比TCP 快，不间断但是不可靠，例如QQ 视频就是使用UDP，经常出现人不动，就是这个原因
分组交换根据其通信子网向端点系统提供的服务，还可以进一步分为面向连接的虚电路方式和无连接的数据报方式。这两种服务方式都由网络层提供。
虚电路在发送方和接受方会建立一条逻辑上的连接，并不是一条真正的物理连接。
电路交换的电话通信是先建立一条真正的物理连接，因此派银分组交换的虚电路和电路交换的连接只是类似，并不完成一样。
1 数据报服务发送分组前不需要建立连接
2 虚电路网络中的每个结点上都维持一张虚电路表，它的每一项记录了一个打开的虚电路的信息，包括在接受链路和发送链路的虚电路号，前一结点和下一结点的标识。
关于拥塞上一张脑图
发生拥塞控制的原因：资源(带宽、交换节点的缓存、处理机)的需求 > 可用资源。作用：拥塞控制就是为了防止过多的数据注入到网络中，这样可以使网络中的路由器或者链路不至于过载。拥塞控制要做的都有一个前提：就是网络能够承受现有的网络负荷。
对比流量控制：拥塞控制是一个全局的过程，涉及到所有的主机、路由器、以及降低网络相关的所有因素。流量控制往往指点对点通信量的控制，是端对端的问题。流量控制只关心发送方和接收方点对点的发送量。它的任务是处理发送能力大于接受能力。
网络中存在太多的数据包，导致数据包被延迟和丢失，从而降低传输性能，这种情况称为拥塞。网络层和传输层共同承担着处理拥塞的责任。
TCP连接的每一端都必须设有两个窗口，一个发送窗口，一个接收端口。
TCP可靠传输机制用字节的序号进行控制。TCP所有的确认基于序号还不是基于报文。TCP 每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。TCP协议用于控制数据段是否需要重传的依据是设立 重传定时器。
保护数据不受主动攻击(数据的伪造和变动)的措施称为报文认证技术。
自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中运输层的错误纠正协议之一。它包括停止等待ARQ协议和连续ARQ协议，错误侦测（Error Detection）、正面确认（Positive Acknowledgment）、逾时重传（Retransmission after Timeout）与负面确认继以重传（Negative Acknowledgment and Retransmission）等。
TCP协议用于控制数据段是否需要重传的依据是设立 重发定时器
3. 计算机网络应用层和传输层及网络层协议有哪些
计算机网络中应用层、传输层和网络层涉及到的一些协议如下：
应用层协议：应用层协议是计算机网络中最高层的协议，用于处理应用程序之间的数据交换。常用的应用层协议包括HTTP、FTP、SMTP、POP3、DNS等。
传输层协议：传输层协议主要弊祥负责实现数据在网络中的可靠传输，通常包括TCP和UDP两种协议。其中，TCP协议提供面向连接、可靠的数据传输，而UDP协议则提供无连接、不可靠的数据传输。
网络层协议：网络层协议主要负责实现数据在网络中的路由和转发，以及网络地址的管桐卜局理。常用的网络层协议包括IP、ICMP、ARP、RARP、OSPF等。其中，IP协议是局让互联网中最重要的协议之一，负责实现数据包在网络中的传输和路由选择。
这些协议在计算机网络中各自扮演不同的角色，共同组成了网络通信的基础框架。应用层协议直接面向用户应用程序，为其提供数据传输和交互的功能；传输层协议则通过TCP或UDP协议保证数据的可靠传输；网络层协议则实现数据在网络中的路由和转发，保证数据能够从源节点到目标节点的可靠传输。
-------FunNet超有趣学网络
4. [计算机网络之六] 传输层
传输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最底层。
从传输层的角度，通信的真正端点并不是主机而是主机中的进程。
传输层有 分用 和 复用 的功能。 “复用” 是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据， “分用” 是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
网络层和运输层有明显的区别，网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。
知名端口号 ：0~1023
登记端口号 ：1024~49151
客户端短暂端口号 ：49152~65535
① 无连接。 发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
② 尽最大努力交付。 即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
③ 面向报文的。 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界，UDP 一次交付一个完整的报文。
用户数据报 UDP 有两个字段：数据字段和首部字段。首部字段很简单，只有 8 个字节，由四个字段组成，每个字段的长度都是两个字节。各字段意义如下：
① 源端口 在需要对方回信时选用。不需要时可用全0。
② 目的端口 目的端口号。这在终点交付报文时必须使用。
③ 长度 用户数据报的长度，最小值为 8 （仅有首部）。
④ 检验和 检测用户数据报在传输中是否有错。有错就丢弃。
用户数据报首部检验和的计算和校验都要计算出一个伪首部。
① 面向连接。
应用程序在使用 TCP 协议之前，必须先建立 TCP 连接；传送数据完毕后，必须释放已经建立的 TCP 连接。类似于打电话：通话前要先拨号建立连接，通话结束后要挂机释放连接。
② 一对一。
TCP 连接只能是点对点的（一对一）。
③ 可靠交付。
通过 TCP 连接传送的数据，无差错、不丢失、不重复，并且按序到达。
④ 全双工通信。
通信双方的应用进程在任何时候都能发送和接收数据，TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。
⑤ 面向字节流。
TCP 中的 “流” 指的是流入到进程或从进程流出的字节序列。
“面向字节流” 的含义：虽然应用程序和 TCP 的交互式一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串无结构的字节流。TCP 并不知道所传送的字节流的含义。TCP 不保证接收方应用程序锁收到的数据块和发送方应用程序所发出的数据块具有对应的大小关系。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样，当然接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。
TCP 连接是协议软件提供的一种抽象，每一条 TCP 连接唯一地被通信两端的两个端点（即两个套接字）所确定，即：
TCP 连接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}
IP1 和 IP2 分别是两个端点主机的 IP 地址，port1 和 port2 分别是两端端点主机中的端口号。
网络只能提供最大努力的服务，是不可靠的，因此 TCP 必须采用适当的措施才能使得两个运输层之间的通信变得可靠。当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告知发送方适当降低发送数据的速度，这样就可以在不可靠的传输信道实现可靠传输。
ARQ（Auto Repeat-reQuest）：自动重传请求。
发送方每发送完一个分组就停止发送，等待接收方确认，在收到确认后再发送下一个分组。
A 是发送方，B 是接收方。
A 每发送一个分组后，等待 B 对该分组的确认后，再接着发送下一个分组。
【发送方】A 发送的分组在传输过程中出错，可能是丢失了，也可能是分组受到干扰出错了
【接收方】这时 B 直接丢弃分组，什么也不做（也不通知 A 受到的分组有差错）。
【解决方案】发送方在每发送完一个分组时设置一个 超时计数器 ，只要超过一段时间仍然没有接收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组，这叫 超时重传 。反之在超时计时器到期之前收到了相应的确认，就撤销该超时计时器。
第一，A 在发送完一个分组后， 必须暂时保留已发送的分组的副本 （在发生超时重传时使用）。只有在收到相应的确认后才能清楚暂时保留的分组副本。
第二，分组和确认分组都必须进行 编号 。这样才能明确是哪一个发送出去的分组受到了确认，而哪一个分组还没有收到确认。
第三，超时计时器设置的 重传时间应当比数据在分组传输的平均往返时间更长一些 。
【发送方】超时重传时间内没有收到确认报文，无法确认是发送出错、丢失，还是接收方的确认丢失，超时计时器到期后就要重传。
【接收方】丢弃收到的重复分组，不向上层交付；向发送方发送确认。
【发送方】收下迟到的确认，并且丢弃
发送方大部分时间都在等待确认，信道的利用率低
使用流水线的 ARQ 可以提高信道利用率
【发送方】维持一个发送窗口，位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。
回退N帧协议 ：如果发送方发送了多个分组，但中间的某个分组丢失了，这时接收方只能对丢失分组之前的分组发出确认，而发送方无法知道丢失分组及后面分组的接收情况，只好把丢失分组及后面的分组重传一次，这叫 Go-back-N ，表示需要再退回来重传已发送过的 N 个分组。
前面 20 个字节固定，因此 TCP 首部最小长度是 20 字节。
TCP 的滑动窗口以字节为单位，窗口后沿的部分表示已发送且已收到通知，窗口里的序号表示允许发送的序号，窗口前沿之前的数据暂时不允许发送，需要等待收到接收方的确认后前沿往前移才可发送。
描述一个发送窗口需要三个指针：P1、P2 和 P3，如图所示：
小于 P1 的是已发送并已收到确认的部分，而大于 P3 的是不允许发送的部分。
P3 - P1 = A 的发送窗口
P2 - P1 = 已发送但尚未收到确认的字节数
P3 - P2 = 允许发送但当前尚未发送的字节数（又称为 可用窗口 或 有效窗口 ）
接收方 B 接收窗口大小为20，因为未收到 31 的数据，即使已收到后面的序号 32、33 的数据，返回的确认号仍然是 31。
现在接收方收到了 31、32、33，并返回确认号 33，接收窗口往前滑动 3 个序号，发送方接收到确认，发送窗口也向前滑动 3 个序号大小，现在 A 可以发送序号 51~53 的数据了。
当发送方将发送窗口内的数据都发送出去，但是接收方的确认可能由于网络拥塞滞留，这时发送方发送窗口已满，可用窗口为 0，只能等待接收方的确认报文到达。
TCP 为了保证可靠传输，要求必须受到对已发送报文的确认，如果超过一定时间未受到确认报文，则重传已发送的报文。这个时间就叫 超时重传时间 ，很明显超时重传时间的大小设置应该更贴近网络的实际情况，如果网络状况好，就设短一点，否则使网络的空闲时间增大，降低了传输效率；网络差就设长一点，否则会引起很多不必要的重传，使网络负荷增大。
TCP 采用了一种自适应的算法：
RTT（报文段的往返时间）、RTTs（加权平均往返时间），RTTs 的计算公式：
RTTd（RTT 的偏差的加权平均值）、RTO（RetransmissionTime-Out 超时重传时间）:
【场景】TCP 的接收方在接收对方发送过来的数据字节流的序号不连续，形成一些不连续的字节块，如果简单按照回退N帧协议处理，意味着要重传第一个未收到的序号数据块及之后的数据，如果能通知发送方已收到了哪些数据（选择确认），就可以让发送方只发送接收方未收到的数据。
流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
当发送方收到接收方通知，将窗口缩小为 0 时，发送方将暂时不能发送数据了，必须等接收方通知更新接收窗口大小，但是这个通知又有可能丢失，导致发送方没收到通知。
为了避免双方互相等待死锁，TCP 为每个链接设有一个 持续计时器 ，只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口 探测报文段 （仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么受到这个报文段的一方就重新设置持续计时器；如果窗口不是零，那么死锁的僵局就可以打破了。
【优点】提高网络利用率
【缺点】可能会发生某种程度的延迟
【场景】接收数据的主机如果每次都立刻回复确认应答的话，可能会返回一个较小的窗口，因为接收方刚接收完数，缓冲区已满。
【糊涂窗口综合征问题】
TCP 接收方缓存已满，而交互式的应用进程一次只从接收缓存中读取 1 个字节（这样就使接收缓存空间仅腾出 1 个字节），然后向发送方发送确认，并把窗口设置为 1 个字节（但发送的数据报是 40 字节长，TCP 首部 + IP 数据报首部）。接着，发送方又发来 1 个字节的数据（注意发送方发送的 IP 数据报是 41 字节长）。接收方发回确认，仍然将窗口设置为 1 个字节。这样进行下去，使网络的效率很低。
TCP 文件传输中，就采用了两个数据段返回一次确认应答，并且等待一定时间后没有其他数据包到达时也依然发送确认应答。
当对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，这种情况就叫做 拥塞 。
慢开始（slow-start）、拥塞避免（congestion avoidance）、快重传（fast retransmit）和快恢复（fast recovery）。
【算法思路】
当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入网络，那么就有可能引起网络发生拥塞。较好的方法是先探测一下，即 由小到大逐渐增大发送窗口 ，也就是说， 由小到大逐渐增大拥塞窗口数值 。
【处理过程】
慢开始门限值 ssthresh 决定了拥塞窗口达到多大时要执行什么算法。
① 当 cwnd < ssthresh 时，使用慢开始算法；
② 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法；
③ 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。
在拥塞窗口 cwnd 达到门限值之前，发送方每一轮次收到确认应答后，cwnd 就增大为原来的两倍；达到门限值后，执行拥塞避免算法。
PS. 慢开始只是表示初始发送数据少，不代表发送速率增长速度慢，实际上是指数级增长非常快。
【算法思路】
让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是像慢开始阶段那样加倍增长。拥塞避免阶段有 “加法增大” 的特点，按线性规律缓慢增长，使网络比较不容易出现拥塞 。
【处理过程】
在执行拥塞避免算法阶段，当网络出现超时时，发送方判断为网络拥塞，调整门限值为当前拥塞窗口的一半，即 ssthresh = cwnd / 2，同时拥塞窗口重置为 1，即 cwnd = 1，进入慢开始阶段。
【算法原理】
① 快重传
【场景】有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞，导致发送方错误地启动慢开始，把拥塞窗口 cwnd 又设置为 1，因而降低了传输效率。
【方案】接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认，当发送方 一连收到 3 个重复确认 ，就知道接收方确实没有收到某个报文段，因而应当 立即进行重传 。
② 快恢复：
发送方知道只是丢失了个别的报文段，于是不启动慢开始，而是执行快恢复算法，调整发送方门限值 ssthresh = cwnd / 2，同时设置拥塞窗口 cwnd = ssthresh = 8，并开始执行拥塞避免算法。
拥塞控制的流程如下：
拥塞窗口 cwnd，接收方窗口 rwnd， 发送方发送窗口的上限值 = Min[rwnd, cwnd] 。
① 当 rwnd < cwnd，接收方的接收能力限制发送方窗口大小；
② 当 cwnd < rwnd，网络的拥塞程度限制发送方窗口大小。
【问题背景】
路由器采取分组丢弃策略，即按照 先进先出（FIFO） 规则处理分组，当队列已满时，则丢弃后面到达的分组，这叫 尾部丢弃策略 。
丢失的分组会导致发送方出现超时重传，发送方转而执行慢开始算法，不同分组属于不同 TCP 连接，导致很多 TCP 同时进入慢开始状态，这种现象称为 全局同步 。
【解决方案】
主动队列管理 AQM：不等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组，而是在队列长度达到某个警惕值时就主动丢弃到达的分组，这样就提醒了发送方放慢发送的速率，因而有可能使网络拥塞的程度减轻，甚至不出现网络拥塞。
TCP 是面向连接的协议，运输连接有三个阶段： 连接建立、数据传送、连接释放 。
TCP 连接建立过程要解决的几个问题：
① 使每一方能够确知对方的存在；
② 允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）；
③ 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。
TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 报文段，即 三次握手 。
最初客户端和服务端都处于 CLOSED（关闭） 状态，A（Client）主动打开连接，B（Server）被动打开连接。
一开始，B 的 TCP 服务器进程先创建 传输控制块 TCB ，准备接受客户进程的连接请求。然后服务器进程就处于 LISTEN（收听）状态，等待客户端的连接请求。如有，即作出响应。
第一次握手 ：A 的 TCP 客户进程也是首先创建传输控制块 TCB，准备接受客户进程的连接请求。然后在打算建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN = 1，同时选择一个初始序号 seq = x。TCP 规定，SYN 报文段（即 SYN = 1 的报文段）不能携带数据，但要 消耗掉一个序号 。这时，TCP 客户进程进入 SYN-SENT（同步已发送） 状态。
第二次握手 ：B 收到连接请求报文段后，如同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。请注意，这个报文段也不能携带数据，但同样 要消耗掉一个序号 。这时 TCP 服务器进程进入 SYN-RCVD（同步收到） 状态。
第三次握手 ：TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。TCP 的标准规定，ACK 报文段可以携带数据。但 如果不携带数据则不消耗序号 ，在这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接） 状态。当 B 收到 A 的确认后，也进入 ESTABLISHED（已建立连接）状态。
数据传输结束后，通信的方法都可释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。
第一次挥手 ：A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u，它等于前面已传送过的数据的最后一个字节的序号加 1。这时 A 进入 FIN-WAIT-1（终止等待 1）状态，等待 B 的确认。请注意，TCP 规定，FIN 报文段即使不携带数据，它也消耗掉一个序号。
第二次挥手 ：B 收到连接释放报文后即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v，等于 B 前面已传送过的最后一个字节的序号加 1。然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务器进程这时应通知高层应用程序，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据要发送了，但 B 若发送数，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。A 收到来自 B 的确认后，就进入 FIN-WAIT-2（终止等待 2）状态，等待 B 发出的连接释放报文段。
第三次挥手 ：若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。现假定 B 的序号为 w（在半关闭状态 B 可能又发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK（最后确认）状态，等待 A 的确认。
第四次挥手 ：A 在收到 B 的连接释放报文段后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号是 seq = u + 1（根据 TCP 标准，前面发送过的 FIN 报文段要消耗一个序号）。然后进入 TIME-WAIT（时间等待）状态。请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器（TIME-WAIT timer）设置的时间 2MSL 后，A 才进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果 B 一收到 A 的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，B 结束 TCP 连接的时间要早于 A。
5. 网络基础-传输层, 网络层数据链路层
同轴电缆: 半双工通讯;
集线器: 类似同轴电缆, 半双工通讯;容易冲突;
网桥: 两个接口, 通过自学习记录每个接口侧的 mac 地址;从而起到隔绝冲突域的作用;
交换机: 相当于接口更多的网桥, 全芹携橘双工通讯;
路由器: 可以在不同网段之间发送数据, 隔绝广播域;
IP地址的组成嫌团:
IP地址有两部分组成: 网络标识(网络ID, 网段), 主机标识( 主机ID);
如何避免浪费IP资源?
信道:信息传输的通道, 一条传输介质上(比如网线), 可以有多条信道;
单工通信: 信号只能往一个方向传, 任何时候不能改变信号的方向;
半双工通信:信号可以双向传播, 但是必须交替进行, 同一时间只能往一个方向传播;
全双工通信:信号可以同时双向传播;
数据帧:数据链路层
如何确保一个数据帧的完整性:
帧的尾部有FCS标识符是根据帧首和帧尾计算得来的, 在获得一个帧数据后帧首帧尾根据计算计算如果值等于FCS则数据帧完整, 去掉帧首帧尾即可获得中间的数据buffer;
数据链路层的数据(MTU)大小为不超过1500个字节,因此我们可以推断出传输层的数据段最大为不超过1460字节;(网络层的首部最小20个字节, 传输层首部最小20个字节, 因此传输层的数据段最大为1460);
ping 的几个用法:
通过tracert, pathping ip地址的方式, 可以查看途径的路由器;
TTL : Time To Live(生存时间) 每经过一个路由器值就会减1; 为0时数据包不再传输;
端口:
UDP首部中端口是占用2个字节(因此其取值范围是0-65535);
防火墙可以可以设置开启/关闭某些端口提升安全性;
常用命令:
传输层的两个协议
TCP: 传输控制协议;
UDP: 用户数据报协议;
TCP的数据格式:
TCP标志位的作用:
如果数据超时或者收到三次确认都会重新发送保证数据完整性;
主要是通过ARQ(自动重传技术-超时重发)+滑动窗口协议实现(例如一次可以接收4个数据包, 就是隐洞一个缓冲区的设置);
另外通过SACK(选择性确认)来告诉发送方哪些数据已经接收到哪些数据丢失, 这样TCP就只发送丢失的部分即可;
如果接收方的数据缓冲区已经满了, 而发送方还在不停的发数据, 则需要进行流量控制;如果不进行控制则接收方只能将大量的数据包进行丢弃, 造成的大量的网络资源浪费;
什么是流量控制?
让发送方的发送速度不要太快, 让接收方有足够的时间和空间来处理和接受数据;注意这个概念是指点对点之间;
原理:
通过确认报文中的窗口字段来控制发送方的发送速率;
发送方的发送窗口大小不能超过接收方的窗口大小;
当发送方收到接收方的窗口为0时则不再发数据;
特殊情况:
刚开始接收方发送了0窗口报文给发送方, 然后发送方停止了发送数据;
后面接收方有空间了, 发送了非0窗口报文给发送方结果报文丢失了;
则接收方和发送方陷入循环;
解决方案: 发送方收到0窗口报文的时候停止发送数据, 同时开启一个定时器, 隔一段时间发送测试报文取询问接收方窗口的大小, 如果仍然收到0窗口报文则重新刷新启动定 时器;
链路的吞吐量在过载的时候会导致拥塞;直观的理解为, 一条路可以同时供100辆车100km/h通过, 但是当有200辆车的时候估计只能以50km/h通过, 当有300辆车时估计会堵的动不了;
拥塞控制是指避免过多的数据注入到网络中, 避免网络中的路由器或者链路过载;拥塞控制是一个全局性的过程, 涉及到所有的主机, 路由器; 是大家共同努力的结果; 注意区分流量控制是点对点之间的;
几个缩写:
MSS: 每个段最大的数据部分大小, 在建立链接是确定;
swnd: 拥塞窗口;
rwnd:接收窗口;
swnd:发送窗口; swnd=min(swnd, rwnd);
拥塞控制思路:
慢开始(慢启动)-拥塞避免- 快速重传-快速恢复;
a. 慢开始 :
b. 拥塞避免 :
c. 快重传 :
d. 快恢复 :
e. 用图片表示拥塞控制
状态解读:
Closed: Client处于关闭状态;
Listen: Server处于监听状态, 等待Client链接;
SYN-RCVD: 表示Server收到SYN报文, 当收到Client的ack报文后进入ESTABLished状态;
SYN-SENT: 表示Client已经发出SYN-SENT报文, 等待Server的第二次握手;
ESTABlished: 已经建立链接;
TCP建立链接前两次握手的特点:
ACK和ack的区别:
大写的ACK(Acknowledgement)是标识位， 可以通过它标识包的性质， [ACK] or [SYC] or [FIN] .
小写的ack(Acknowledgement Number), 是确认号。 即收到seq=x 的数据包后，回复 ack=x+1 的确认。
状态解读
FIN-WAIT1: 表示向主动断开, 向对方发送了FIN报文后进入FIN-WAIT1状态;
CLOSE-WAIT: 表示等待关闭, 当对方发送FIN报文给自己,会回应一个ACK报文, 同时进入CLOSE-WAIT状态, 此状态下如果仍然有数据发送给对方则会继续发送, 如果没有数据发给对方,则发送FIN给对方;
FIN-WAIT2: 主动方收到对方的ACK报文后就会处于FIN-WAIT2状态然后等待对方的FIN报文;
LASK-ACK: 被动一方在发送FIN报文后处于LAST-ACK状态, 收到主动方的ACK报文后就进入CLOSED状态;
TIME-WAIT: 主动方收到对方的FIN报文后回复ACK报文给对方并进入TIME-WAIT状态, 等待2MSL时间后进入CLOSED状态;
如果在FIN-WAIT1状态下同时收到对方的FIN和ACK报文则直接进入TIME-WAIT状态, 无需经过FIN-WAIT2状态;
CLOSED: 关闭状态;
CLOSING: 一种比较罕见的状态, 表示发出FIN报文后没有收到对方的ACK报文反而也收到了FIN报文,即双方几乎同时发送FIN报文时就会进入CLOSING状态;表示双方都在进行关闭链接;
细节补充
为了提高重传的性能; 可靠性传输是在传输层进行控制的;
这个取决于系统的设置, 例如有些系统在重新传输5次后仍然不能成功, 就会发送reset报文( RST )断开TCP链接;
三次握手的目的: 防止服务器端一直等待, 浪费资源;
如果改成两次握手会出现的情况: 假如client客户端第一次发送的请求报文段, 因为网络延迟的原因, 在释放链接后才到达服务器端, 本来这是一个应该失效的请求链接, 但是server端收到这个请求后会误认为这是client发送的新的链接请求, 于是sever端就会再次给client发送确认报文然后建立链接, 等待client发送数据过来, 这样的话, server端就会一直处于链接状态等待;
采用三次握手的方法可以防止上述情况发生:例如上述情况, client没有向server发出确认, server端收不到确认就知道client不是建立链接;
另一种解析的思路 : client和server建立链接是为了相互交换数据, 所以得确保自己和对方的数据收发功能都处于正常状态;
第一次握手: server端可以确认自己的接收功能和client端的发送功能正常;
第二次握手: client端可以确认自己的发送和接收功能都是正常, 并且server端的接收和发送功能都是正常的;
第三次握手: server端确认自己的发送功能和client的接收功能正常;;
第三次握手的时候server处于SYB-RCVD状态, 如果等不到client端的ACK, server端会再次发送ACK+SYN包, 如果多次发送后仍然等不到client的ACK包, 则server端发送RST包, 强制断开链接;
有必要, 而且不能省去, 原因如下: 假如Client在发送ACK报文后立即进入了断开状态, 然后因为网络状态Server端没有收到这个ACK报文则会重发FIN报文给Client, 则可能会出现的情况如下:
a. Client端没有反应, Server重复尝试发送FIN给Client, 浪费资源;
b. Client刚好有个新的应用分配了同一个端口, 新应用本是想建立链接, 结果收到FIN报文后就会进入断开链接操作;
e
6. 计算机网络(5)| 运输层
从通信和处理信息的角度看，运输层是向它上面的应用层提供通信服务的，它属于面向通信部分的最高层，同时也是用户功能中的最低层。当网络的边缘部分中的两台主机使用网络的核心部分的功能进行端到端的通信时，只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。
运输层的两个主要协议 TCP/IP 都是互联网的正式标准，即：
（1）用户数据报协议UDP
（2）传输控制协议TCP
TCP则是面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或者多播服务。由于TCP要提供可靠的面向连接的运输服务，因此需要增加很多的开销。
TCP/IP的运输层用一个16位端口号来标志一个端口。端口号只有本地意义。它是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。
运输层的端口号分为以下两类：
（1）服务器端使用的端口号： 它主要分为系统端口号0～1023和登记端口号1024～49151。
（2）客户端使用的端口号： 49152～65535，这类端口号仅在客户端进程运行时才动态选择。当服务器收到客户端进程的报文时，就知道客户端进程的端口号。因而可以把数据发送给客户进程。
用户数据报协议相比于IP的数据报服务就是只增加了复用、分用和差错检测功能。UDP的主要特点是：
（1）UDP是无连接的， 发送数据之前不需要建立连接，因此减少开销和发送数据之前的时延。
（2）UDP使用尽最大努力交付， 即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
（3）UDP是面向报文的。 发送方的UDP对应用交下来的报文，添加首部后就向下交付给IP层。不对报文做任何处理，因此当报文过长时，IP层可能需要进行分片处理。
（4）UDP没有拥塞控制， 网络出现的拥塞不会使源主机的发送速率减低。
（5）UDP支持一对一、一对多、多对一和多对多的交互通信。
（6）UDP的首部开销小， 只有8个字节。
UDP有两个字段：数据字段和首部字段。先介绍首部字段，它是由4个字段组成的，每个字段只有2个字节，总共有8个字节。各个字段的意义如下：
（1）源端口： 源端口号。在需要对方回信时选用。不需要时可用全0。
（2）目的端口： 目的端口号。在这终点交付报文时必须使用。
（3）长度： UDP用户数据报的长度，其最小值是8（只有首部）。
（4）检验和： 检测UDP用户数据报在传输中是否有错，有错则丢弃。
当在传送用户数据报时，如果接收方UDP发现收到的报文中目的端口号不正确（即不存在对应于该端口号的应用进程），就丢弃该报文，并由网际控制报文协议ICMP发送“端口不可达”差错报文给发送方。
TCP的主要特点如下：
（1）TCP是面向连接的运输层协议。 应用程序在使用TCP协议之前，必须先建立TCP连接。传送数据完毕后，必须释放TCP连接。
（2）每一条TCP连接只能有两个端点。 每一条TCP连接只能是点对点的。
（3）TCP提供可靠交付的服务。 通过TCP连接传送的数据，无差错、不丢失、不重复，并且按序到达。
（4）TCP提供全双工通信。 TCP允许通信双方的应用进程在任何时候都能发送数据。
（5）面向字节流。 TCP中的流指的是流入到进程或进程流出的字节序列。虽然应用程序和TCP的交互是一次一个数据块，但TCP把应用程序交下来的数据看成一连串的无结构的字节流。TCP不保证发送方发送的数据块和接收方接收的数据块一致，但保证程序接收到的字节流和程序发送的字节流一致。
TCP连接的端点叫做套接字或者插口。套接字是指将端口号拼接到IP地址之后，即：
每一条TCP连接唯一的被通信两端的两个端点所确定。即：
如图所示，A发送分组M1，发送完毕就暂停发送，等待B的确认,B收到了M1就向A发死你确认。A在收到了对M1的确认之后，就再发送下一个分组M2，以此类推。
如图所示，当B接收M1时检测出了差错，就丢弃M1，其他什么也不做。而A只要超过了一段时间没有收到确认，就会认为刚才发送的分组丢失了，因而重传前面发送过的分组，这就叫做超时重传，而实现超时重传则需要A为每一个已发送的分组都设置一个超时计时器。
需要注意以下三点：
（1）A在发送完一个分组后，必须暂时保留已发送的分组的副本。
（2）分组和确认分组必须编号，这样才能明确哪一个发出的分组收到了确认。
（3）超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长。
如图所示，B所发送的对M1确认丢失了，A在设定的超时重传时间内没有收到确认，所以无法知道自己发送的分组是怎样出错的，所以会重传M1，而当B又收到了重传的分组M1，这时应该采取两个行动：
（1）丢弃这个重复分组M1。
（2）向A发送确认。
还有一种情况就是在传输过程中没有出现差错，但B对分组M1的确认迟到了，而A会收到重复的确认，A收下后就会丢弃，B仍然会收到重复的M1，并且同样要丢弃重复的M1，并且重传确认分组。
停止等待协议的优点是简单，缺点则是信道的利用率太低。我们用TD表示A发送分组需要的时间，TA表示B发送确认分组需要的时间，RTT为往返时间，则：
为了提高传输的效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输的方式。即不必每发完一个分组就停下来等待对方的确认，这样就可以使信道上一直有数据在不间断的传送。
如图表示的是发送方维持的发送窗口，它指的是位于发送窗口内的5个分组都可以连续发送出去而不需要等待对方的确认。同时连续ARP协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
对于接收方采用的则是累计确认的方式，即接收方不必对收到的分组逐个发送确认。而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了。这种方式的优点是：容易实现，即使确认丢失也不必重传（意思是发送方不必重传）。但缺点是不能向发送方反映出接收方已经正确收到的所有分组信息。
TCP虽然是面向字节流的，但传送TCP的数据单元却是报文段。一个TCP报文段可以分为首部和数据两部分。
为了后面讲述的方便，我们假设数据传输只在一个方向进行，即A发送数据，B给出确认。
TCP的滑动窗口是以字节为单位的。如图所示，现在假定A收到了B发来的确认报文段，其中的窗口是20字节，而确认号是31，根据这2个数据，A就构造出自己的发送窗口。
发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。发送窗口后面的部分表示已发送且已经收到了确认。而发送窗口前沿的部分表示不允许发送的。
现在假定A发送了序号为31~41的数据。这时发送窗口位置并未改变但是发送窗口内靠后面有11个字节表示已发送但是未收到确认。而发送窗口内靠前面的9个字节时允许发送但未发送的。如图所示：
而对于B，它的接收窗口大小是20，在接收窗口外面到30号位置的数据是接收并确认的，因此可以丢弃。在下图中，B收到了32和33的数据，但它们不是按序到达的，因为并没有收到31号数据。B只能对按序达收到的数据中的最高序号给出确认，因此B发送的确认报文字段的确认号依然是31号。
现在假定B收到了序号为31的数据，并把31～33的数据交付主机，然后B删除这些数据。接着把窗口向前移动3个序号，同时给a发送确认，其中的窗口值仍为20，但确认号变为34。表明B已经收到序号33为止的数据。
因为TCP的发送方在规定的时间内没有收到确认就要重传已经发送的报文段，但是重传时间的选择却TCP最复杂的问题之一。为此TCP采用了一种自适应算法，它记录了一个报文段发出的时间以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT，同时TCP保留了RTT的加权平均往返时间RTTs。而RTTD是RTT的偏差加权平均值，它与RTTs和新的RTT样本之差有关。
超时重传时间的算法如下：
第一次测量时，加权平均往返时间取往返时间RTT，以后每次测量到一个新的RTT，按以下公式计算：
第一次测量时，RTT偏差的加权平均等于RTT的一半，以后的测里中，按以下公式计算：
综上超时重传时间RTO计算如下：
若收到的报文无差错，只是未按序号，使用选择确认SACK可是让发送方发送那些未收到的数据，而不重复发送已经收到的那些数据。如果要使用选择确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，并且双方必须都事先商量好。
流量控制就是指让发送方的发送速率不要太快，要让接收方来得及接收。而利用滑动窗口机制就可以很方便的在TCP连接上实现对发送方的流量控制。
如上图所示，接收方B进行了三次流量控制。第一次把窗口减小到rwnd=300，第二次又减到rwnd=100，最后是rwnd=0，即不允许发送方再发送数据了。
但是我们应该考虑一种情况，就是当接收方B的存储已满时，会向发送方发送零窗口的报文段，接着B的存储又有了一些空间，B再向A发送一个不为零的窗口值，但这个报文丢失了，结果就是双方一直等待下去。所以为了解决这个问题，TCP为每一个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，当计时器到期后，就发送一个探测段文段，而对方就在确认这个探测段时给出了现在的窗口值。如果窗口仍然是0，那么收到这个报文段的一方就重新设置持续计时器，反之则死锁的僵局就可以打破了。
应用程序把数据传送到TCP的发送缓存后，TCP在何时发送这些数据？，在TCP的实现中广泛使用了Nagle算法。具体算法如下：
（1）若发送应用进程要把数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发出去，把后面到达的数据字节都缓存起来。
（2）方发送方收到对第一个数据字节的确认后，再把发送缓存中的所有数据组装成一个报文发送出去，同时继续对后续到来的数据进行缓存。
（3）只有收到对前一个报文段的确认后才继续发送下一个报文段。
当数据到达快而网络速度慢时，这种方法可以明显减少网络带宽。Nagle还规定：当到达的数据达到窗口的一半或最大报文长度时就立即发送一个报文。
但还还需要考虑一个叫做糊涂综合征的问题，具体内容是若接收方的缓存已满，应用进程每次只从缓存中取1个字节，然后向发送方确认，并把窗口设为1个字节（缓存只空了1个字节的空间），接着发送方发来1个字节，接收方发回确认，仍然将窗口设为1，这样进行下去，网络的利用率很低。
为了解决这个问题，可以让接收方等待一段时间，使得或者缓存已有足够的空间或者等到接收缓存已有一半的空闲空间。此时，接收方就发出确认报文，并向发送方通知当前窗口的大小。
拥塞 是指在某一段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏的情况。而所谓的 拥塞控制 就是防止过多的数据注入到网络当中，这样可以使网络中的路由器或者链路不致过载，它是一个全局性的过程，涉及到所有的主机和路由器，而流量控制往往是指点对点通信量的控制。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。
TCP进行拥塞控制的算法有4种：慢开始、拥塞避免、快重传和快恢复。下面在讨论这些算法时我们假定：
（1）数据是单方向传送的，对方只传送确认报文。
（2）接收方总是有足够大的缓存空间。
发送方维持一个拥塞窗口的状态变量，其大小取决于拥塞程度，并且动态变化。发送方让自己的发送窗口小于拥塞窗口（如果考虑接收方的接收能力的话，发送窗口可能小于拥塞窗口）。发送方控制拥塞窗口的原则是：只要网络没有拥塞，拥塞窗口就再增大一点，以便把更多的分组发送出去，只要出现拥塞，就减小拥塞窗口，以减少注入到网络的分组数。
下面会从“慢开始算法”讲起来讨论拥塞窗口的大小如何变化的。
慢开始的算法思路是：当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络中，就有可能引起网络拥塞。因此会采用由小逐渐增大发送窗口。即在通常开始发送报文时，先将拥塞窗口cwnd的值设为一个最大报文段MSS的数值，而在每收到一个新的报文段确认后，把拥塞窗口增加至多一个MSS的数值。
如上图所示，开始时cwnd=1，发送方发送一个M1，接收方收到M1发送确认，发送方收到一个确认后将cwnd加1，此时cwnd=2，因此发送方发送M2和M3两个报文段，接收方收到后返回两个确认，因此cwnd增加两次，此时cwnd=4，接着发送方发送M4～M7四个报文段。依次类推。因此使用慢开始算法后，每经过一个传输轮次，拥塞窗口就加倍。
但是为了防止拥塞窗口cwnd增加过大导致网络拥塞，需要设置一个慢开始门限ssthresh，慢开始门限用法如下：
当cwnd<ssthresh时，使用上述的慢开始算法。
当cwnd>ssthresh时，停止使用慢开始算法，使用拥塞避免算法。
当cwnd=ssthresh时，既可以使用慢开始算法，也可以使用拥塞避免算法。
这里的拥塞避免算法是指让拥塞窗口缓慢的增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是像慢开始阶段那样加倍增长。
需要注意的是无论在慢开始阶段还是拥塞避免阶段，只要发送方判断网络出现拥塞（根据是没有按时收到确认），立即把慢开始门限ssthresh设为出现拥塞时的发送窗口的一半。然后发送窗口cwnd重新设为1，执行慢开始算法。目的是迅速减少主机发送到网络分组的分组数。
快重传算法要求接收方每收到一个失序的报文段后就立即发送重复确认，如下图接收了M1和M2后，又接收到一个M4，M4属于失序报文，则发送对M2的重复确认。发送方只要连续收到三次确认重复就立即重传对方未收到的报文段M3。
与快重传算法配合的还有快恢复算法，过程如下：
（1）当发送方连续收到三个重复确认时，就把慢开始门限ssthresh减半，这是为了防止网络拥塞，接着并不执行慢开始算法。
（2）由于上图这种情况很可能不是因为网络拥塞引起的，因此这里不执行慢开始算法（即不把拥塞窗口cwnd设为1，这样速度太慢），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法。
TCP的运输连接有是三个阶段：连接建立、数据传送和连接释放。在TCP的连接过程中要解决以下三个问题：
（1）要使每一方能够确知对方的存在。
（2）要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量）。
（3）能够对运输实体资源进行分配。
TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换3个TCP报文段。如图是三报文握手建立的连接过程：
A最后还要发送一次确认的原因是为了防止已经失效的连接请求报文段突然又传送到了B，因而产生错误。试想一种情况：如果只有第一次和第二次握手，第二次B向A发送的确认丢失了，此时B进入了连接建立状态，A没有收到确认，过一段时间后会再次向B发送连接请求，B收到后又会再次建立连接，白白浪费B的资源。
A在TIME-WAIT状态等待2MSL（MSL，最长报文段寿命），主要是因为以下两点考虑：首先是为了保证A发送的最后一个ACK报文段能够到达B，因为这个ACK报文段可能丢失，此时B会重传连接释放报文，如果A已经关闭，则无法收到这个报文。其次，当A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续时间内产生的所有报文段都从网络中消失。这样，下一个新连接中不会出现这种旧的连接请求报文段。
在图中每一个方框即TCP可能具有的状态。每个方框中的大写英文字符串时TCP标准所使用的的TCP连接状态名。状态之间的箭头表示可能发生的状态变迁。箭头旁边的字表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作，在图中粗实线箭头表示对客户进程的正常变迁，粗虚线箭头表示对服务器进程的正常变迁，细线箭头表示异常变迁。
7. 三.传输层
传输层的 核心任务 ： 应用进程 之间提供 端到端 的 逻辑通信 服务
回顾：只有 主机 才有传输层，网络核心中的路由器、交换机、集线器等只用到 下三层 的功能
记：分复流拥寻差错-可靠
一台计算机中，不同应用进程用 进程标识符(进程ID) 来区分
网络环境下：
TCP/IP 体系结构网络的解决方法：
在传输层使用协议端口号，通常简称为端口(port)， 在全网范围内利用 IP地址+端口号 唯一标识一个通信端行辩点
传输层端口号为16位整数，可以编号65536个(2的16次方）
常用端口： 端口号小于256的端口
传输层端口号：
1、服务器端使用的端口号：熟知端口号和登记端口号
2、客户端使用的端口号临时性，在客户进程运行时由操作系统随机选取唯一的未被使用的端口号：
多路复用 ：在源主机，传输层协议从不同的套接字收集应用进程发送的数据块，并为每个数据块封装上首部信息(包括用于分解的信息)构成报文段，然后将报文段传递给网络层
多路分解 ： 在目的主机，传输层协议读取报文段中的字段，标识出接收瞎带腊套接字，进而通过该套接字，将传输层报文段中的数据交付给正确的套接磨滑字
多路复用与多路分解(复用与分解/复用与分用)： 支持众多 应用进程共用 同一个传输层协议，并能够将接收到的数据准确交付给 不同的应用进程
用户数据报协议(User Datagram Protocol, UDP)：Internet提供无连接服务的传输层协议
UDP套接字二元组：<目的IP地址，目的端口号>
传输控制协议(Transmission Control Protocol, TCP)： Internet提供面向连接服务的传输层协议
TCP套接字四元组: <源IP地址，源端口号，目的IP地址，目的端口号>
基于不可靠信道实现可靠数据传输采取的措施
差错检测：利用编码实现数据报传输过程中的比特差错检测
确认： 接收方向发送方反馈接收状态。 ACK(肯定确认) ；NAK(否定确认)
重传：发送发 重新 发送接收方没有正确接收的数据
序号：确保数据按序提交(对数据进行编号，即便不按序到达，可以按序提交)
计时器： 解决 数据丢失问题
TCP提供可靠数据传输服务
UDP不提供可靠数据传输服务
最简单的自动重传请求协议是停等协议
流水线协议：管道协议，允许发送方在没有收到确认前连续发送 多个 分组
最典型的流水线协议： 滑动窗口协议
1、 增加分组序号
2、发送方和接收方可以缓存多个分组
发送方的发送窗口：发送方可以发送未被确认分组的最大数量
接收方的接收窗口: 接收方可以缓存到正确到达的分组的最大数量
发送：
接收：
滑动窗口协议：根据窗口的大小，可以具体分为：
回退N步协议：GBN协议(Go-Back-N)
选择重传协议：SR协议(Selective Repeat)
GBN协议： 发送窗口>=1； 接收窗口=1 ；
发送端 缓存能力高，可以在没有得到确认前发送多个分组
接收端 缓存能力很低，只能接收一个按序到达的分组，不能缓存未按序到达的分组
GBN发送方响应的3类事件：
SR协议： 发送窗口>1 接收窗口>1
发送端缓存能力高
接收端缓存能力高
SR发送方响应事件：
用户数据协议（User Datagram Protocal, UDP）: Internet 传输层 协议，提供 无连接 、不可靠、数据报尽力传输服务
0-15-31： 32位二进制
UDP首部四个字段： 每个字段长度都是2字节，共8个字节
源端口号和目的端口号：UDP实现复用和分解
长度：指示UDP报文段中的字节数(首部和数据的总和)
校验和：接收方使用检测数据报是否出现差错
应用数据字段：应用层数据占用
UDP校验和：提供差错检测功能
UDP的校验和用于检测UDP报文段从源到目的地传送过程中，其中的数据是否发生了改变
UDP校验和计算规则
1、所有参与运算的内容按16位对齐求和
UDP校验和计算的内容包括3部分：UDP伪首部、应用数据
传输控制协议(Transmission Control Protocol ,TCP): Internet 传输层协议
提供面向连接、可靠、有序、字节流传输服务
第一：应用进程 先建立连接
第二：每一条TCP连接只有 两个 端点
第三： 可靠交付 ：无差错、不丢失、不重复、按序到达
第四： 全双工 通信
第五：面向 字节流
流：字节序列，应用程序和TCP的交互是一个个数据块，TCP把他们看做是无结构字节流
1、源端口号字段、目的端口号字段：占16位、复用和分解上层应用的数据
2、序号字段、确认序号字段：占32位
序号字段：TCP序号是对每个应用层数据的每个字节进行编号
确认序号字段：期望从对方接受数据的字节序号，即该序号对应的字节尚未收到
9.选项字段长度可变，最短为0字节，最长为40字节
TCP连接管理：连接建立与连接拆除
以客户端上的一个应用进程与服务器上的一个应用进程建立一条TCP连接为例
一、建立连接
第一次握手：
客户向服务器发送连接请求段：(SYN=1, seq=x)
SYN = 1; 建立连接请求控制段
seq=x; 表示传输的报文段第1个数据字节的序列号是x，此序列号代表整个报文段的序号
客户端进入SYN_SEND （同步发送）
第二次握手：
服务端发回确认报文段：(SYN=1, ACK=1,seq=y,ack_seq=x+1)
SYN=1 同意建立新连接的确认段
ack_seq = x + 1; 表示已经收到序列号为x的报文段，准备接受序列号为x+1的报文段
seq=y : 服务器告诉客户确认报文段的序列号是y
服务器由LISTEN进入SYN_RCVD（同步收到）
第三次握手
客户端对服务器的同意连接报文段进行确认：(ACK=1,seq=x+1, ack_seq=y+1)
seq=x+1 : 客户端此次的报文段的序列号是x+1;
ack_seq = y+1 : 客户端期望接收服务器序列号y+1的报文段
当客户端发送ACK时，客户端进入ESTABLISHED状态
当服务端收到ACK后，也进入ESTABLISHED状态
第三次 握手可携带数据
二、连接拆除：四次挥手
第一次挥手
客户端向服务器发送释放连接报文段：(FIN=1, seq=u)
FIN=1.发送端数据发送完毕，请求释放连接
seq=u 传输的第一个数据字节的序号是u
客户端状态由ESTABLISHED进入FIN_WAIT_1(终止等待1状态)
第二次挥手
服务器向客户发送确认段：（ACK=1, seq=v, ack_seq=u+1）
ACK=1； 确认字号段有效
ack_seq=u+1 : 服务器期望接受客户数据序号为u+1
seq=v: 服务器传输的数据序号是v
服务器状态由ESTABLISHED进入CLOSE_WAIT(关闭等待)
客户端收到ACK段后，由FIN_WAIT_!进入FIN_WAIT_2
第三次挥手
服务器向客户发送释放连接报文段：(FIN=1, ACK=1, seq=v+1, ack_seq=u+1)
FIN =1: 请求释放连接
ACK = 1：确认字号段有效
ack_seq=u+1: 表示服务器期望接受客户数据序列号为1
seq=v+1 表示自己传输的第一个数据字节的序号是v+1
服务器状态由CLOSE_WAIT进入LAST_ACK(最后确认状态)
第四次挥手：
客户向服务器发送确认段：（ACK=1,seq=u+1,ack_seq=w+1）
ACK=1: 确认字号段有效
ack_seq=v+1+1 : 表示客户期望接受服务器数据序号为v+1+1
seq=u+1 表示客户传输的数据的序号是u+1
客户端状态由FIN_WAIT_2进入TIME_WAIT 等待2MSL时间，进入CLOSED状态
服务器再收到最后一次ACK后，由LAST_ACK进入CLOSED
一、可靠：保证接收方应用进程从缓冲区读出的字节流与发送发发出的字节流是完全一样的
二、TCP实现可靠数据传输服务的工作机制
1、应用层数据被 分割 成TCP认为最适合发送的数据块
2、序号,发送方对发送的数据包进行编号，确保数据按序提交给接收方 采用累积确认
3、确认，接收方向发送方反馈接收状态，确认是否正确接收数据
4、差错检测，利用差错编码实现数据包传输过程中的比特差错检测（甚至纠正）
5、重传，发送方重新发送接收方没有正确接收的数据
6、计时器，在发送方引入计时器，解决数据丢失问题
最大报文段长度：1500字节
报文段中封装的应用层数据的最大长度：1480字节 = 1500 - 最短的首部长度
TCP生成ACK的策略
流量控制：协调发送方与接收方的数据发送与接收 速度
在通信过程中，接收方设置报文段的 接收窗口字段 来将窗口大小通知给发送方
一、网络拥塞： 太多的主机``以太快的速度 向网络中发送 太多的数据 ，超出了网络处理能力，导致大量数据分组拥挤在中间设备队列中等待转发， 网络性能 显着下降的现象
二、拥塞控制：通过合理调度、规范、调整向网络中发送数据的主机数量、发送速率、数据量、以 避免 拥塞或 消除 已发生的拥塞
三、概念补充介绍
四、TCP拥塞控制算法
阈值之前：慢启动阶段
阈值之后：拥塞避免阶段
l例如： 发生计时器超时，当前拥塞窗口24MSS，当前阈值为16MSS
新的阈值：为当前拥塞窗口的一半，新的阈值=24/2=12MSS
新的拥塞窗口：直接调整为1MSS 新的拥塞窗口=1MSS
调整好新的阈值和新的拥塞窗口之后，使用 慢启动。拥塞避免 算法增加拥塞窗口大小
例如：发送3次重复确认时，当前拥塞窗口为24MSS，当前阈值为16MSS
新的阈值：为当前拥塞窗口的一半
新的拥塞窗口：调整为新的阈值
调整好新的阈值和新的拥塞窗口后，使用 拥塞避免 算法增加拥塞窗口大小
五、窗口调整的基本策略（Additive Increase，Multiplicative Decrease, AIMD）:
网络未发生拥塞时：逐渐"加性"增大窗口
网络拥塞时“乘性”减小窗口
六、拥塞预防策略：流量整型技术：规范主机向网络发送数据的流量
8. 计算机网络传输层
端到端的连接
网络层：提供主机之间的逻辑通信
传输层慎销宽：提供应用进程之间的逻辑通信
位于网络层之上、依赖网络层服务、对网络层服务进行可能的增强
接收端：多路分用
相同目的地址目的端口号的UDP会被导向同一个socket
每个srcIp srcPort DestIp DestPort 导向自宽亮己独有的socket(创建多个socket)
(服务器也可以让一个进程创建多个线程与tcp连接绑定)
发送端：多路复用
什么是可靠？ 不错、不乱、不丢
可靠数据传输协议
GBN
1.发送方 分组头部包含k-bit序列号
窗口尺寸为N，最多允许N个分组未确认
序列号 ：表示本报文段所发送数据的第一个字节的编号。而不是报文段的编号（这里防止被攻击混入其他的段难以检测的问题）。
建立TCP连接时，双方随即选择序列号
ACKs 表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。
累计确认：该序列号之前所有的字节均已被正确接收到（GBN）
TCP在IP层提供的不可靠服务基础上实现可靠数据传输服务
流水线机制
累积确认
TCP使用单一重传定时器
触发重传的事件
超时
收到重复ACK
渐进式
暂不考虑重复ACK
暂不考虑流量控制
暂不考虑拥塞控制
1.点对点 一个sender 一个 reciever
2.可靠的、按序的字节流
3.流水线机制
案例：
何时应该指数性增长切换为线性增长(拥塞避免)?
当CongWin达到Loss事件前值的1/2时.
实现方法:利用一个变量 Threshold， Loss事件发生时, Threshold被设为Loss事件前CongWin值的1/2。
Loss事件处理办法
3个重复ACKs:CongWin切到一半然后线性增长
Timeout事件:CongWin直接设为1个MSS，然后指数增长，达到threshold后, 再线性增长（拥塞更严重了）
TCP拥塞控制算法
4.接收方/发送方缓存
5.全双工：同一连接中能传输双数据流
6.面向连接(连接管理)
TCP连接包括：两台主机上的缓存、连接状态变量、socket等
客户端初始化的序列号是随机的
7.流量控制机制：发送方不会传输的太多、太快以至于淹没接收方（buffer溢出）
8.复用/分用
1.基于“尽力而为”的网络层，没有做（可靠性）
丢失
非按序到达
2.基于Internet IP协议
复用/分用
简单的错误校验
3.无连接
UDP发送方和接收方之间不需要握手
每个UDP段的处理独立于其他段
UPD优点：
1.无需建立连接（减少延迟）-DNS
2.实现简单，无需维护连接状态
3.头部开销小（8byte）
4.没有拥塞控制：应用可更斗简好的控制发送时间和速率
常用于流媒体应用
1.容忍丢失
2.速率敏感
DNS/SNMP
在UDP上实现可靠数据传输
UDP校验和：检测UDP段在传输过程中是否发生错误
9. 【网络协议笔记】第四层:传输层(Transport)TCP协议简介(1)
TCP有以下几个知识点。
图片备用地址
图片备用地址
TCP的几个要点：可靠传输、流量控制、拥塞控制、连接管理（建立和释放连接）。
也正因为这几点使得首部变得很复杂。
占4位，取值范围是0x0101 ~ 0x1111。
乘以4就是首部长度（Header Length）。所以取值范围是5 ~ 60字节，由于首部固定部分占用20字节，所以可选部分至多占用40字节（和网络层首部一样）。
为什么叫数据偏移？因为相对TCP报文向右偏移首部长度后就是数据部分。
UDP的首部中有个16位的字段记录了整个UDP报文段的长度（首部 + 数据）。
但是，TCP的首部中仅仅有个4位的字段记录了TCP报文段的首部长度，并没有字段记录TCP报文段的数据长度。
分析：UDP首部中占16位的长度字段是冗余的，纯粹是为了保证首部是32bit对齐。
TCP/UDP的数据长度，完全可以由IP数据包的首部推测出来，传输层的数据长度 = 网络层的总长度 - 网络层的首部长度 - 传输层的首部长度。
占6位，目前全为0。
与UDP一样，TCP检验和的计算内容：伪首部 + 首部 + 数据。伪首部占用12字纳枯丛节，仅在计算检验和时起作用，并不会传递给网络层。
图片备用地址
一共占6位或9位。
有些资料中，TCP首部的保留（Reserved）字段占3位，标志（Flags）字段占9位。Wireshark中也是如此。是因为标志位中的前3位是无用的，所以两种说法都不能说是错的。
图片备用地址
图片备用地址
意思：紧急。当URG=1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送。
紧急指针存放的是长度值，表示TCP的前多少字节是需要紧急优先处理的。
意思：确认。当ACK=1时，确认号字段才有效。
意思：推。一般用在交互式网络中。PUSH标志位所表达的是发送方通知接收方传输层应该尽快的将这个报文段交给应用层。
意思：重置。当RST=1时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接。
意思：同步。当SYN=1 & ACK=0时，表明这是一个建立连接的请求。若对方同意建立连接，则回复SYN=1 & ACK=1。
请求方再发送SYN=0 & ACK=1时表明开始传输数据。这也是三次握手的流程。
意思：完成。表明数据已经发送完毕，要求释放连接。
占4字节。首先，传输的每一个字节都会有一个编号（连续的字节编号也是连续的）。
在建立连接后，序号代表这一次传给对方的TCP数据部分的第一个字节的编号。
占4字节。在建立连接后，确认号代表期望对方下一次传过来的TCP数据部分的第一个字节的编号。
占2字节。这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）。
ARQ(Automatic Repeat-reQuest), 自动重传请求。
图片备用地址
无差错情况
A发送数据M1到B，B收到数据M1后向A发送确认信号M1；
A收到确认信号M1后，继续洞樱向B发送数据M2，B接收后向A发送确认信号M2。
超时重传
A发送数据M1到B，A在发送数据途中丢包败蔽或B发现数据M1有错误直接丢掉，导致B无法向A发送确认信号M1；
A在一定时间间隔后发现没有收到B发送的确认信号M1，A会继续向B发送数据M1；
B收到数据M1后向A发送确认信号M1，A收到确认信号M1后，继续向B发送M2数据。
通过确认与超时重传机制实现可靠传输，在发送完一个分组后，必须暂时保留已发送的分组的副本。
分组和确认分组都必须进行编号。超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。
图片备用地址
确认丢失
A发送数据M1到B，B接收到数据M1后，向A发送确认信号M1；
B在向A发送确认信号M1中途丢包，此时A在一定时间间隔后发现没有收到B发送的确认信号M1，A会继续向B发送数据M1；
B收到数据M1后会丢弃重复的数据M1（之前已经收到数据M1，只是A不知道），继续向A发送确认信号M1；
A收到确认信号M1后，继续开始发送M2数据。
确认迟到
A发送数据M1到B，B接收到数据M1后，向A发送确认信号M1；
B在向A发送确认信号M1时，由于网络延迟等原因导致A在一定时间段内未收到确认信号；
A会继续向B发送数据M1，B收到数据M1后丢弃重复的数据M1，并向A发送确认信号M1；
A收到确认信号M1后，继续开始发送M2数据，M2数据刚发送出去，此时A刚好接收到B在第一次发送的确认信号M1，
但由于之前已经成功接收并处理了第二次的确认信号M1，所以A在收到确认信号后什么也不做。
出现差错或丢失的时候，发送方会将自己备份的副本再重传一次，直到收到接收的确认信息。
当接收方收到重复的数据时，会直接丢弃，但是会给发送方请确认自己已经收到了。
上面的停止等待协议每发送一组数据就必须等到接收方回复确认后，再发起第二组数据，如果出现超时重传的话，效率更低。
因此为了提高传输的效率，改进了等待传输协议。
连续ARQ协议和滑动窗口协议的机制是以接收方回复确认为单位，每次连续发送一个滑动窗口指定的数据组。
图片备用地址
A发送数据给B时，一次性发送M1~M4（A和B建立连接时，B告诉A自己的缓存池可以容纳多少字节数据，
A根据这个缓存池的大小构建一个同大小的发送窗口–也可以理解为发送缓存池），此时A开始等待确认，B收到全部数据后会向A发送确认信号M4（以最后一个编号为准）；
A收到确认信号后，继续向B发送M5 M8（A把之前构建的窗口滑动并锁定到对应大小的数据段上，即M5 M8），以此往复直到数据传输完毕。
如果接收窗口最多能接收4个包（窗口大小），但发送方只发了2个包，接收方如何确定后面还有没有2个包？
答案：接收方会在等待一定时间后发现没有第3个包，就会返回收到2个包的确认信号给发送方。
滑动窗口是由发送方维护的类似指针的变量，在每收到一个接收方的确认消息后，
该指针向前移动并发送数据，到窗口指定大小的数据组时停下，等待接收方的确认。
图片备用地址
累积确认机制： 发送方不对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，
这样就表示：到这个分组为止的所有分组都已正确收到了。
优点：容易实现，即使确认丢失也不必重传。
缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。
Go-back-N（回退 N）： 为了解决上述同一窗口中数据组不能完整确认的问题，连续ARQ协议采用了回退机制。
比如说：发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。
发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做 Go-back-N（回退 N），表示需要再退回来重传已发送过的N个分组。
结论：当通信线路质量不好时，连续ARQ协议会带来负面的影响。可能还不如传统的停止等待协议。
TCP连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。
TCP的可靠传输机制用字节的序号进行控制。TCP所有的确认都是基于序号而不是基于报文段。
TCP两端的四个窗口经常处于动态变化之中。
TCP连接的往返时间RTT也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。
滑动窗口是面向字节流的，为了方便记住每个分组的序号，
现在假设有一个1200字节的数据，分12组，每一组数据是100个字节，代表一个数据段的数据（每一个数据都有自己的TCP首部），每一组给一个编号（1~12）。
图片备用地址
图片备用地址
TCP通信时，如果发送序列中间某个数据包丢失，TCP会通过重传最后确认的分组后续的分组，这样原先已经正确传输的分组也可能重复发送，降低了TCP性能。
SACK（Selective Acknowledgment，选择确认）技术 ，使TCP只重新发送丢失的包，不用发送后续所有的分组，
而且提供相应机制使接收方能告诉发送方哪些数据丢失，哪些数据已经提前收到等。
在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。
原来首部中的“确认号字段”的用法仍然不变。只是以后在TCP报文段的首部中都增加了SACK选项，以便报告收到的不连续的字节块的边界。
图片备用地址
Kind：占1个字节，值为5代表这是SACK选项。
Length：占1个字节，表明SACK选项一共占用多少字节。
Left Edge：占4个字节，左边界。
Right Edge：占4个字节，右边界。
图片备用地址
上图的着色模块代表已接收数据，空白代表未接收数据。左右边界意思是会把未接收完毕的TCP数据包的已接收数据进行左右标记。
由于TCP的选项不能超过40个字节，去除Kind和Length占用的2个字节，还剩下38个字节给左右边界使用。
一组边界占用8个字节（左右边界各占4个字节），所以边界不能超过4组。也能够因此推断出SACK选项的最大占用字节数是4 * 8 + 2 = 34。
思考：超过选项边界的数据怎么办？
超过边界的数据需要重新传输，但这已经很大程度提高了传输效率。
重传机制是TCP中最重要和最复杂的问题之一。TCP每发送一个报文段，就对这个报文段设置一次计时器。
只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。那么这个重传时间到底应该设置多少呢？建议跳过，有兴趣的可以去查阅相关资料。
图片备用地址
为什么选择在传输层就将数据分割成多个段，而不是等到网络层再分片传递给数据链路层？
-->网络层没有可靠传输协议，丢包无法只发送一个报文段，所以需要分割成多个段。
如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传
如果在传输层分段了，一旦出现数据丢失，只需要重传丢失的那些段即可
欢迎大家的意见和交流
email: [email protected]