Ⅰ 计算机网络传输层
端到端的连接
网络层：提供主机之间的逻辑通信
传输层慎销宽：提供应用进程之间的逻辑通信
位于网络层之上、依赖网络层服务、对网络层服务进行可能的增强
接收端：多路分用
相同目的地址目的端口号的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段在传输过程中是否发生错误
Ⅱ [计算机网络之六] 传输层
传输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最底层。
从传输层的角度，通信的真正端点并不是主机而是主机中的进程。
传输层有 分用 和 复用 的功能。 “复用” 是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据， “分用” 是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
网络层和运输层有明显的区别，网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。
知名端口号 ：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。
Ⅲ [计算机网络]Ch.6 传输层
为什么需要两个不同的独立控制层
传输层的主要功能
传输层是整个协议栈(TCP/IP)的核心，传输层的任务是提供 可靠的、高效的 数据传输
传输层使整个报文到达了该计算机上正确的进程
传输层的最终目标是向它的用户（应用层）提供高效、可靠和性价比高的服务【例如从一台主机到另一台主机的报文到底送给这台机器的email去解析，还是送给播放器播放，还是浏览器解析】
端口（port）定义
16 位，共有 216个端口
端口范围：0~65535
<1023 : 用于公共应用（保留，全局分配，用于标准服务器），IANA分配；
1024~49151 :用户端口，注册端口；
> 49152 : 动态端口，私人端口。
TCP (Transmission Control Protocol) 是专门为了 在不可靠的互联网络 上提供 可靠的端到端字节流 而设计的
TCP必须 动态地适应 不同的拓扑、带宽、延迟、分组大小和其它的参数，并且当有错误的时候，能够足够 健壮
TCP服务模型：
TCP头部范围（5x4B 15x4B（最大数值））--（20B 60B）
释放连接
两军队问题
难题在于最后发送的一方永远无法知道自己的信 对方有无收到 。
为了避免两军队（two-army）问题，使用定时器
半开放连接（half- open）
TCP是全双工的，连接必须是双向的。半开半闭的连接必须杀掉
TCP 传输策略
发送方（Nagle’s algorithm）
接收方（Clark’s solution）
分组守恒 ：当有一个老的分组离开之后才允许新的分组注入网络
TCP希望通过 动态维护窗口大小 来实现这个目标
拥塞检测Congestiondetection 拥塞标记
所有的互联网TCP算法都假定 超时 是 由拥塞引起的 ，并且通过监视超时的情况来判断是否出现问题
拥塞控制Congestionprevention
慢启动算法（Slow Start） (尝试的过程)：
如：如果试图发送 4096 字节没有问题，但是发送8192字节的时候，超时没有收到应答，则拥塞窗口设为4096个字节
最重要的定时器是 重传定时器
持续定时器（persistence timer） ，用来 避免如下的死锁 （ deadlock ）发生
保活定时器（keep-alive timer）
TCP
Ⅳ 计算机网络_运输层
在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 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。
下面的执行步骤就是按照折现上的点的顺序