本文共 16678 字，大约阅读时间需要 55 分钟。
目录
运输层和网络层的区别：
类似于家庭间通信：
A家庭的12个孩子要与B家庭的12个孩子相互通信从通信和信息处理的角度看，传输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最底层。为运行在不同主机上的进程之间提供了逻辑通信。
网络的边缘部分的两台主机使用网络核心部分的功能进行端到端的通信时，只有主机的协议栈才有传输层和应用层，而路由器在转发分组时都只用到下三层的功能（即 在通信子网中没有传输层，传输层只存在于通信子网以外的主机中）。
传输层提供应用层之间的逻辑通信（即 端到端的通信）。与网络层的区别是，网络层提供的是主机之间的逻辑通信。
逻辑通信：传输层之间的通信好像是沿水平方向传送数据，但事实上这两个传输层之间并没有一条水平方向的物理连接。
分用：（一段数据→多个进程）是指接收方的传输层在剥去报文的首部后能够把这些数据正确交付到目的应用进程。
注意：传输层的复用分用功能与网络层的复用分用功能不同。
网络层的复用是指发送方不同协议的数据都可以封装成IP数据报发送出去，分用是指接收方的网络层在剥去首部后把数据交付给相应协议。
提供两种不同的传输协议，即 面向连接的TCP和无连接的UDP。而网络层无法同时实现两种协议（即 在网络层要么只提供面向连接的服务，如虚电路；要么只提供无连接服务，如数据报，而不可能在网络层同时存在这两种方式
TCP和UDP分别拥有自己的端口号，它们互不干扰，可以同时实现。
传输层向高层用户屏蔽了低层网络核心的细节（如网络拓扑、路由协议等），它使应用进程看见的是好像在两个传输层实体之间有一条端到端的逻辑通信信道，这条通信信道对上层的表现却因传输层协议不同而有很大的差别。
TCP时，尽管下面的网络是不可靠的，当这种通信信道就相当于一条全双工的可靠信道。UDP时，这种逻辑通信信道仍然是一条不可靠信道。
原本进程是用进程标识符来标志的。但运行在应用层的各种应用程序却不应当让计算机操作系统指派它的进程标识符，往往需要利用目的主机提供的功能来识别终点，而不需要知道实现这个功能的进程。
协议端口号(Protocol port number)，通常简称为端口(port)。
注意与路由器的物理端口区分。
端口是传输层的服务访问点(TSAP)，用来表示主机中的应用进程。（数据链路层的SAP是MAC地址，网络层的SAP是IP地址，用来标识主机）
服务访问点(service access point, SAP)：实际就是逻辑接口，是一个层次系统的上下层之间进行通信的接口，N层的SAP就是N+1层可以访问N层服务的地方。
端口号只具有本地意义，即 端口号只是为了标志本计算机应用层中的各进程。在互联网中，不同计算机的相同端口号是没有联系的。
由此可见，两个计算机中的进程要互相通信，不仅必须知道对方的IP地址（为了找到对方的计算机），而且还要知道对方的端口号（为了找到对方计算机中的应用进程）。
套接字：
在网络中通过IP地址来标识和区别不同的主机，通过端口号来标识和区分一台主机中的不同应用进程。在网络中采用发送方和接收方的套接字(Socket)组合来识别端点。
所谓套接字，实际上是一个通信端点，即 套接字=（主机IP地址，端口号）
套接字的长度为48位：32位IP地址+16位端口号。
它唯一地标识网络中的一台主机和其上的一个应用（进程）。
进程通过套接字来接收和发送报文，套接字相当于一个通道。
常用的熟知端口：
| 协议 | 应用程序 | 名称 | 端口号 |
|---|---|---|---|
| UDP | RPC | 实时传输协议 | 111 |
| DNS | 域名系统 | 53 | |
| DHCP | 动态主机设置协议 | 67,68 | |
| TFTP | 简单文件传输协议 | 69 | |
| SNMP | 简单网络管理协议 | 161 | |
| SNMP(trap) | 162 | ||
| TCP | SMTP | 简单邮件传输协议 | 25 |
| POP | 邮局协议 | 110 | |
| FTP | 文件传输协议 | 21,20 | |
| Telent | 远程终端协议 | 23 | |
| HTTP | 超文本传输协议 | 80 | |
| HTTPS | 超文本传输安全协议 | 443 |
无连接服务：是指两个实体之间的通信不需要先建立好连接，需要通信时，直接将信息发送到“网络”中，让该信息的传递在网上尽力而为地往目的地传送。
无连接的用户数据报协议(UDP)，传输层向上提供的是一条不可靠的逻辑信道。由于UDP比较简单，因此执行速度比较快、实时性好，主要用于小文件传送协议(TFTP)、DNS、SNMP和实时传输协议(RTP)。
面向连接服务：是指在通信双方进行通信之前，必须先建立连接，在通信过程中，整个连接的情况一直被实时地监控和管理。通信结束后，应该释放这个连接。
面向连接的传输控制协议(TCP)，传输层向上提供的是一条全双工的可靠逻辑信道。主要适用于可靠性更重要的场合，如文件传输协议(FTP)、超文本传输协议(HTTP)、远程登录(TELENT)等。
注意：虽然连接→可靠，但是可靠≠连接，“可靠”指的是使用确认机制来确保传输的数据不丢失。
RFC768定义的用户数据报协议(UDP，User Datagram Protocol)只是做了传输协议能够做的最少工作，它仅在IP的数据报服务之上增加了两个最基本的服务：复用和分用以及差错检测。
面向报文。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。UDP一次交付一个完整的报文。
因此报文不可分割，是UDP数据报处理的最小单位。
首部开销小，只有8个字节，比TCP的20个字节首部要短
校验和：2字节。检测UDP数据报在传输中是否有错，有错就丢弃。（二进制反码运算求和再取反）
注意：检验和字段是可选的，当源主机不想计算校验和，则直接令该字段全为0.（校验时计算出则16位字的和，无差错时结果应全为1（因为校验和是它们和的反码，所以加上校验位应该要全为1））
二进制反码求和：规则是从低到高位逐列进行计算。0和0加得0，0和1加得1，1和1加得0但要产生一个进位1，加到下一列。若最高位产生了进位，则最后得到的结果要加1。
传输控制协议(TCP，Transmission Control Protocol)是在不可靠的IP层之上实现的可靠的数据传输协议，它主要解决传输的可靠、有序、无丢失和不重复问题。
面向字节流：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据看成仅仅是一连串无结构的字节流。
TCP中的“流”(stream)指的是流入或流出进程的字节序列。
TCP报文段既可以用来运载数据，又可以用来建立连接、释放连接和应答。（TCP也有伪首部，但此处不写）
数据偏移（即 首部长度）：占4bit，单位为4B，指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。单位为32bit(以4B为计算单位)（如数据偏移=15时，首部长度=15*4B=60B）。
保留字段：占6bit。保留为今后使用，但目前应置为0。
紧急位URG(URGent)：占1bit。当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送。(一般不使用)
确认位ACK(ACKnowledgement)：占1bit。只有当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。
推送位PSH(PuSH)：占1bit。接收TCP收到推送比特置1的报文段，就尽快地交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。
复位位RST(ReSeT)：占1bit。当RST=1时，表明TCP连接中出现严重差错(如由于主机崩溃或其他原因)，必须释放连接，然后再重新建立运输连接。
终止位FIN (FINal)：占1bit。用来释放一个连接。当FIN=1时，表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。
窗口字段：占2字节。窗口字段用来控制对方发送的数据量，单位为字节。TCP连接的一端根据设置的缓存空间大小确定自己的接收窗口大小，然后通知对方以确定对方的发送窗口的上限。
校验和：占2字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。
紧急指针字段：占16bit。紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。
选项字段（长度可变）：TCP只规定了一种选项，即最大报文段长度MSS (Maximum Segment Size)。MSS告诉对方TCP:“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节。”（因为通常字节数都很大，所以用MSS来计字节数，更方便一些）
填充：这是为了使整个首部长度是4字节的整数倍。
TCP是面向连接的协议，因此每个TCP连接都有三个阶段：连接建立、数据传送和连接释放。
第一步：客户机的TCP首先向服务器的TCP发送一个连接请求报文段。其首部中的SYN标志位被置为1（“要同步连接了”），客户机会随机选择一个起始序号字段seq=x（“我的起始序号为x”）（作为最开始的起始序号，要被消耗）。（连接请求报文不携带数据，但要消耗一个序号）
注意：因为客户机还没协商确定发送的起始序号，连接请求报文不携带数据，但要消耗一个序号。
第二步：服务器的TCP收到连接请求报文段后，若同意连接，就发送一个确认报文段，并为该TCP连接分配TCP缓存和变量。SYN=1（“要同步连接了”）,ACK=1（“确认收到了连接”），确认号字段ack=x+1（“我收到你发过来的序号x的报文段了，我现在想要你的x+1”），并且服务器随机产生起始序号字段seq=y（“我的起始序号为y”）。（确认报文不携带数据，但也要消耗一个序号）
注意：因为服务器还没协商确定发送的起始序号，确认报文不携带数据，但也要消耗一个序号。
第三步：但客户机收到确认报文段后，还要向服务器给出确认收到，并且也要给该连接分配缓存和变量。ACK=1（“确认收到了”）,seq=x+1（“给你发序号x+1的报文段”）,ack=y+1（“我想要你的y+1”）。（该报文段可以携带数据，若不携带数据则不消耗序号）
注意：因为此时双方已经协商好了发送的起始序号，所以可以携带数据了。
该报文段可以携带数据，若不携带数据则不消耗序号。
注意：服务器端的资源是在完成第二次握手时分配的，而客户端的资源是在完成第三次握手时分配的，这就使得服务器易于受到SYN泛洪攻击。
ACK=1, seq=x+1, ack=y+1
注意：SYN泛洪攻击就是因为发送方发送SYN报文后（第一次握手），接收方发送确认报文并等待，结果发送方不发了。导致资源的浪费。
参与TCP连接的两个进程中的任何一个都能终止该连接。
第一步：客户机打算关闭连接时，向其TCP发送一个连接释放报文段，并停止发送数据，主动关闭TCP连接。FIN=1（“我发完了，要释放了”）,seq=u（它等于前面已传送过的数据的最后一个字节的序号+1）（“我现在给你发下一个报文段：u，虽然没啥可发的了，意思一下”）。（FIN报文段即使不携带数据，也要消耗一个序号）
注意：因为客户机不想发数据了，所以FIN报文段不携带数据，也要消耗一个序号（这个序号没有要传送的字节）来表示不发了。
但TCP是全双工的，客户机不发送数据了，但服务器还可以发送数据。
第二步：服务器收到连接释放报文段后即发出确认。ACK=1（“确认收到了”）,seq=v（序号等于前面已传送过的数据的最后一个字节的序号+1）（“你发完了，我还没发完呢，我给你发下一个报文段：v”）,ack=u+1（“我收到你发过来的u了，我现在期望收到u+1”）。
注意：服务器还是想发送数据的，所以确认报文段可以携带数据。
此时，从客户机到服务器这个方向的连接就释放了(即 A→B断开)，TCP连接处于半关闭状态。当服务器若发送数据，客户机仍要接收，即 从服务器到客户机这个方向的连接并未关闭(即 B→A连接)注意：服务器发送数据，客户端接收时，发送确认接收，seq=u+1（“你怎么还想要啊，我没有数据了，给你个u+1意思一下，最后一次了啊”）（因为服务器期望得到下一个报文段：u+1）（这个u+1就不变了，一直是u+1，因为客户端没有数据要发了）,ack=v+n（n按序增加）。
第三步：若服务器已经没有要向客户机发送的数据，就通知TCP释放连接，发送连接释放报文段。FIN=1（“我也发完了，释放吧”）,ACK=1（“确认知道你要释放了，巧了，我也想释放”）,seq=w（“我现在给你发下一个报文段：w，虽然我也没啥可发的了，但是意思一下也不坏”）,ack=u+1（“你这u+1给我发的什么啊，怎么什么都没有，再给我发一次”）。
注意：两者都没有报文段要发了，所以不携带数据了。
第四步：客户机收到连接释放报文段后，必须发出确认报文段。ACK=1（“确认收到了”）,seq=u+1（“给你给你，你要的u+1”）,ack=w+1（“我现在想要下一个w+1”）。（但是这个已经得不到回应了，服务器已经发完了）（所以客户机等了一会要不到，就关闭了）
注意：此时TCP连接还未释放，必须经过时间等待计时器设置的时间2MSL后，A才进入连接关闭状态。
科普：MSL 是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。也就是说，我们要等2MSL才能保证本连接次序的时间内所产生的所有报文段从网络中消失，即 客户端刚发送的ACK消失、并且服务器可能没收到后重发的FIN消失，这两个事件的最长时间就是MSL，这样才能保证服务器确实收到了客户端的ACK。
ACK=1, seq=u+1, ack=w+1
注意：ACK、SYN、FIN一定等于1。
SYN、FIN都不携带数据，只表示控制报文段。
注意：
四次挥手需要特别注意两个状态，CLOSE-WAIT和TIME-WAIT状态。CLOSE-WAIT：（第二次挥手到第三次挥手之间）客户端发完数据了，半关闭了，我们服务器还没发完，继续发，等待发完之后关闭。TIME-WAIT：（第四次挥手等待）客户端等2MSL再关闭。参考文章：
考虑这种情况：主机A发出的请求报文段在某些网络节点滞留时间太长，主机A由于超时重发连接请求，收到B的确认建立连接。数据传输完毕释放连接。这时第一个请求才到达B，主机B收到该失效的请求后，误以为A又发出请求，于是向主机A发出确认，同意建立连接。主机A则不会理睬该确认。主机B则苦等A的数据。三次握手就可以防止这种情况的发生。（主机A不会对主机B的确认发出确认，连接就建立不起来）
其实为什么不用二次握手，总结下来就是一对小情侣的故事。
为何不采用“三次挥手”释放连接，且发送最后一次握手报文后要等待2MSL的时间呢？
防止出现“已失效的连接请求报文段”。A在发送最后一个确认报文段后，再经过2MSL可保证本连接次序的时间内所产生的所有报文段从网络中消失。造成错误的情形与不采用“两次握手”建立连接所描述的情形相同。
注意：服务器结束TCP连接的时间要比客户端早一些，因为客户机最后要等待2MSL后才可进入CLOSED状态。
了解TCP协议端口的连接状态，对排除和定位网络或系统故障会有很大帮助，因此了解一下是有必要的：
提供某种服务，侦听远方TCP端口的连接请求，当提供的服务没有被连接时，处于LISTENING状态，端口是开放的，等待被连接。
客户端调用connect，发送一个SYN请求建立一个连接，在发送连接请求后等待匹配的连接请求，此时状态为SYN_SENT。
在收到和发送一个连接请求后，等待对方对连接请求的确认，当服务器收到客户端发送的同步信号时，将标志位ACK和SYN置1发送给客户端，此时服务器端处于SYN_RCVD状态，如果连接成功了就变为ESTABLISHED，正常情况下SYN_RCVD状态非常短暂。
ESTABLISHED状态是表示两台机器正在传输数据。
等待远程TCP连接中断请求，或先前的连接中断请求的确认，主动关闭端应用程序调用close，TCP发出FIN请求主动关闭连接，之后进入FIN_WAIT1状态。
从远程TCP等待连接中断请求，主动关闭端接到ACK后，就进入了FIN-WAIT-2 .这是在关闭连接时，客户端和服务器两次握手之后的状态，是著名的半关闭的状态了，在这个状态下，应用程序还有接受数据的能力，但是已经无法发送数据，但是也有一种可能是，客户端一直处于FIN_WAIT_2状态，而服务器则一直处于WAIT_CLOSE状态，而直到应用层来决定关闭这个状态。
附半关闭例图：
等待从本地用户发来的连接中断请求，被动关闭端TCP接到FIN后，就发出ACK以回应FIN请求（它的接收也作为文件结束符传递给上层应用程序），并进入CLOSE_WAIT。
等待远程TCP对连接中断的确认，处于此种状态比较少见。
等待原来的发向远程TCP的连接中断请求的确认，被动关闭端一段时间后，接收到文件结束符的应用程序将调用CLOSE关闭连接，TCP也发送一个 FIN，等待对方的ACK，进入LAST-ACK。
在主动关闭端接收到FIN后，TCP就发送ACK包，并进入TIME-WAIT状态，等待足够的时间以确保远程TCP接收到连接中断请求的确认，很大程度上保证了双方都可以正常结束，但是也存在问题，须等待2MSL时间的过去才能进行下一次连接。
被动关闭端在接受到ACK包后，就进入了closed的状态，连接结束，没有任何连接状态。
附TCP正常连接建立和终止所对应的状态图
a、客户端：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSEDb、服务端
CLOSED->LISTEN->SYN_RECEIVED->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSE在众多状态中，经常关注的有两个：TIME_WAIT、CLOSE_WAIT。
附状态迁移过程图：
补充文章：
TCP的任务是在IP层不可靠的、尽力而为服务的基础上建立一种可靠数据传输服务，保证接收方进程从缓存区读出的字节流与发送方发出的字节流完全一致。
TCP使用了校验、序号、确认和重传等机制来达到这一目的。
TCP连接的往返时间RTT也不是固定不变的（由于网络流量的变化,这个时间会相应地发生改变），需要使用特定的算法估算较为合理的重传时间。
超时：TCP每发送一个报文段，就对这个报文段设置一次计时器。计时器设置的重传时间到期但还未收到确认时，就要重传这一报文段。
由于TCP的下层是一个互联网环境，IP数据报所选择的路由变化很大，因而传输层的往返时延的方差也很大。为了计算超时计时器的重传时间，TCP采用一种自适应算法，它记录一个报文段发出的时间，以及收到相应确认的时间，之差为RTT。
加权平均往返时间\(RTT_S\)：（其中权值0≤α<1）
\[新RTT_S=(1-α)*(旧RTT_S)+α*(新RTT样本)\]若选择α→0，表示新RTT标准值与旧RTT标准值相比变化不大，且受新RTT样本的影响不大（RTT值更新较慢）。
若选择α→1，则表示新RTT标准值受新RTT样本的影响较大（RTT值更新较快）。RFC2988推荐的α值是0.25。
显然，超时计时器设置的超时重传时间(Retransmission Time-Out, RTO)应略大于上面得出的加权平均往返时间\(RTT_S\)，计算公式如下：
\[RTO=RTT_S+4*RTT_D\]其中\(RTT_D\)是RTT的偏差的加权平均值。它与\(RTT_S\)和新RTT样本之差有关。
第一次测量时，\(RTT_D\)取为测量到的RTT样本值的一般，在以后的测量中，使用下式计算：
\[新RTT_D=(1-β)*(旧RTT_D)+β*|RTT_S-新RTT样本|\]式中，β是个小于1的稀疏，它的推荐值是0.25。
冗余ACK（冗余确认）：（即 相同的ACK多了很多）
超时触发重传存在的一个问题是超时周期往往太长。所幸的是，发送方通常可在超时事件发生之前通过注意所谓的冗余ACK来较好地检测丢包情况。
TCP规定当发送方收到对同一个报文段的3个冗余ACK时，就可以认为这个报文段已经丢失。
例如，发送方A发送了序号为1、2、3、4、5的TCP报文段，其中2号报文段在链路中丢失，当3、4、5到达B时，B会一连发送3个期望得到2号的冗余ACK。这意味着在2号之后的三个报文段都到了，2号还没到，就可以认为它丢失了。发送方A立即对2号报文进行重传，而不是等到超时没有收到确认之后，重传。
采用可滑动窗口机制，装在发送端（发送窗口）和接收端（接收窗口）。
一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。流量控制(flow control)就让让发送方的发送速度不要太快，既要让接收方来得及接收，又不要使网络发送拥塞。
发送窗口（双方商定）：在建立时由双方商定。
接收窗口rwnd(receiver window)（接收端确定）（免得收不了）：在通信过程中，接收端可根据自己的接收缓存的大小，通过接收端向对方发送的TCP报文段首部的“窗口”字段，即 接收端窗口rwnd(receiver window)，向发送方通报接收端缓冲区的接收能力，从而动态地随时调整控制发送端的发送窗口的上限值。
拥塞窗口cwnd(congestion window)（发送端确定）（免得发出去堵车）：发送端根据其对当前网络拥塞程度的估计而确定的窗口值。其大小与网络的带宽和时延密切相关。
注意：只有发送窗口和接收窗口是滑动窗口，拥塞窗口只是一个由当前网络状况决定的数值（用来决定发送窗口），而不是滑动的窗口。
rwnd由接收端根据其接收缓存确定，发送端确定cwnd比较复杂，其涉及TCP的网络拥塞控制。
窗口的移动：
窗口两个边沿的相对运动增加或减少了窗口的大小。
TCP要求接收方必须有累积确认的功能（一次确认一个报文段，而不是对每个字节都要发回确认），这样可以减小传输开销。
注意：TCP是面向字节的。对每个字节进行编号，但并不是收到每个字节都要发回确认，而是在发送一个报文段的字节后，才发回一个确认，所以TCP采用的是对报文段的确认机制。
拥塞控制：是指防止过多的数据注入网络，以使网络中的路由器或链路不至于过载。
拥塞控制：是让网络能够承受现有的网络负荷，是一个全局性的过程。（如 当发生堵车时，如何进行疏散，是拥塞控制）
拥塞控制是不要搞太多数据，没有拥塞控制会噎着
TCP发送方维持一个拥塞窗口CWND(Congetsion Window)
注意：拥塞窗口的大小是由下面介绍的拥塞控制机制来控制的。
重传定时器超时：
现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的（远小于1%）。只要出现了超时，就可以猜想网络可能出现了拥塞。
收到三个相同（重复）的ACK
个别报文段会在网络中丢失（接收方没有收到，连续发了三个相同ACK），预示着可能会出现拥塞（实际未发生拥塞），因此可以尽快采取控制措施，避免拥塞。
拥塞窗口是卫星通信在因特网中防止通信拥塞的一种措施，它是一个装在发送端的可滑动窗口。
拥塞窗口只是一个由当前网络状况决定的数值（用来决定发送窗口），而不是滑动的窗口。
拥塞窗口cwnd控制方法：在每收到一个对新的报文段的确认后，可以把拥塞窗口cwnd+1，即 增加最多一个MSS的数值。很显然，这是一个指数增长，每经过一个传输轮次，拥塞窗口就加倍。每次*2。
例如，发送一个，确认一个，cwnd+1=2；发送两个，确认两个，cwnd+2=4；发送四个，确认四个，cwnd+4=8...
一个传输轮次所经历的时间其实就是往返时间RTT。
当cwnd=ssthresh时，即可以使用慢开始算法，也可以使用拥塞避免算法。
实际应用中，相等时往往使用拥塞避免算法。
网络拥塞的处理：
当网络出现拥塞时，无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（重传定时器超时）
执行慢开始算法
这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
注意：这个图代表第n次传输后的拥塞窗口数值。
传输次数为0时，代表初始拥塞窗口为1，代表第0次传输后拥塞窗口为1；而第一次传输结束后（这个横坐标就代表传输结束后的值），拥塞窗口变为了2（即 代表第一次传输时的拥塞窗口是1，而传输第一次传输结束后拥塞窗口就变为了2；2作为第二次传输时的拥塞窗口进行传输）。（即 经过1个RTT后，拥塞窗口为2）（也可以说是收到第1个确认段后，拥塞窗口变为了2）
| 传输次数 | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| 拥塞窗口 | 初始为1 | 第一次传输后变为了2 | 第二次传输后变为了4 | 第三次传输后变为了8 |
| 备注 | 第一次传输时传输1 | 第二次传输时传输2 | 第三次传输时传输4 | 第四次传输时传输8 |
快重传和快恢复算法是对慢开始和拥塞避免算法的改进。
采用快重传FR (Fast Retransmission)算法可以让发送方尽早知道发生了个别报文段的丢失。
使用快重传可以使整个网络的吞吐量提高约20%。
不难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。
开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。（“加法增大”(Multiplicative Decrease, MD)）
由于跳过了cwnd从1起始的慢开始过程，所以被称为快恢复。
注意：实际上，慢开始、拥塞避免、快重传和快恢复几种算法应是同时应用在拥塞控制机制之中的。
当发送方检测到超时的时候，就采用慢开始和拥塞避免；当发送方接收到冗余ACK时，就采用快重传和快恢复。
当cwnd<rwnd时，则是网络的拥塞限制发送窗口的最大值。
也就是说，rwnd和cwnd中数值较小的一个，控制了发送方发送数据的速率。
拥塞避免(+1)
我的理解：
此时拥塞窗口到达门限了，所以用拥塞避免(+1)
注意：
超时的时候cwnd被置为1：（因为超时的时候，一个ACK都没有传过来，网络拥塞很严重，所以发送方得最大限度地一直数据发送量）三个冗余ACK的时候cwnd减半：（因为收到三个冗余ACK的时候，代表有三个ACK报文段能被正确交付，网络拥塞没有那么严重，所以减半）
1.对比
| UDP | TCP | |
|---|---|---|
| 是否连接 | 无连接 | 面向连接 |
| 是否可靠 | 不可靠传输，不使用流量控制和拥塞控制 | 可靠传输，使用流量控制和拥塞控制 |
| 连接对象个数 | 支持一对一，一对多，多对一和多对多交互通信 | 只能是一对一通信 |
| 传输方式 | 面向报文 | 面向字节流 |
| 首部开销 | 首部开销小，仅8字节 | 首部最小20字节，最大60字节 |
| 适用场景 | 适用于实时应用（IP电话、视频会议、直播等） | 适用于要求可靠传输的应用，例如文件传输 |
2.总结
长度：是UDP数据报整个的长度（包括首部和数据），单位为1B
注意：因为UDP数据报首部长度是固定的8B（没有可变部分），所以没有必要再设置首部长度字段。
首部长度（只有首部），单位为4B。
注意：因为最大报文段长度MSS是约定好的，所以不需要整个长度，只用知道首部长度。
片偏移：占13位，单位为8B
记忆方法：你不要总是拿1条首饰（首4）来骗（偏）我吧（8）
首部长度都是以4B为单位（首部长度较短，无需精确单位）（IPv6首部长度必须是8B的整数倍），总长度都是以1B为单位（总长度需要精确的单位），片偏移都是以8B为单位（因为数据较长，所以单位大一些，无需精确单位，每个分片的长度一定是8B的整数倍（除最后一个片外））。
IP数据报：只检查IP数据报的首部（因封装变大了，所以只检验首部）
注意：IP数据报每经过一个路由器，路由器都要重新计算校验和（一些字段，比如生存时间、片偏移等可能发生变化）；不校验数据部分，主要是为了减少软件计算量。
IPv6不进行首部检查和，从而更快速处理IP分组。
转载地址：http://eytkz.baihongyu.com/