tcp连接格式(tcp半连接)

在cmd运行窗口中输入DOS命令netstat，即可查看电脑的tcp连接。具体操作请参照以下步骤。1、进入电脑系统后，在键盘上同时按下“win+R”键，调出运行窗口。2、然后在出现的窗口中，输入“cmd”字样，点击确定按钮。3、然后便会进入到cmd的运行界面中，如图所示。4、然后再输入DOS命令【netstat】，再按键盘上的回车键。5、完成以上设置后，即可查看电脑的tcp连接情况。
如何查看tcp连接的几种方法：方法一：通过命令提示符程序（cmd.exe）。第一步，查看TCP连接使用命令netstat -ano -p tcpnetstat -ano | find "ESTABLISHED"注释：1.如果使用find就不用再使用-p来指定是不是tcp协议了。2.参数-o表示显示发起连接的进程的ID（PID）（Displays the owning process ID associated with each connection.）注意：中英文符号的输入差别。第二步，使用tasklist列出发起连接的进程。使用命令：tasklist | find "4288"注释：tasklist命令本身有很可以使用和有用的参数，如使用筛选器（/FI    filter）和指定输出格式（/FO    format），但这里使用了find，所以依然不需要指定任何参数。方法二：使用PowerShell轻松查看，一行命令出结果。方法三：在图形界面窗口中，通过Windows自带的“资源管理器（Resource Monitor）”来查看TCP连接。较快捷的打开方法是先打开“任务管理器（Task Manager，Ctrl+Shift+Esc）”，然后切换到“性能（Performance）”，在窗口右下角就能找到（可能需要管理员权限）。
建议你可以用抓包软件Wireshark进行抓包，然后进行分析，可以清楚的看到每一次连接（三次握手）和每一次释放（四次握手）；包括帧的格式都清楚可见……

ISO制定的OSI参考模型的过于庞大、复杂招致了许多批评。与此对照，由技术人员自己开发的TCP/IP协议栈获得了更为广泛的应用。 如图所示，是TCP/IP参考模型和OSI参考模型的对比示意图。在TCP/IP参考模型中，去掉了OSI参考模型中的会话层和表示层（这两层的功能被合并到应用层实现）。同时将OSI参考模型中的数据链路层和物理层合并为主机到网络层。下面，分别介绍各层的主要功能。实际上TCP/IP参考模型没有真正描述这一层的实现，只是要求能够提供给其上层-网络互连层一个访问接口，以便在其上传递IP分组。由于这一层次未被定义，所以其具体的实现方法将随着网络类型的不同而不同。网络互连层是整个TCP/IP协议栈的核心。它的功能是把分组发往目标网络或主机。同时，为了尽快地发送分组，可能需要沿不同的路径同时进行分组传递。因此，分组到达的顺序和发送的顺序可能不同，这就需要上层必须对分组进行排序。网络互连层定义了分组格式和协议，即IP协议（Internet Protocol）。网络互连层除了需要完成路由的功能外，也可以完成将不同类型的网络（异构网）互连的任务。除此之外，网络互连层还需要完成拥塞控制的功能。在TCP/IP模型中，传输层的功能是使源端主机和目标端主机上的对等实体可以进行会话。在传输层定义了两种服务质量不同的协议。即：传输控制协议TCP（transmission control protocol）和用户数据报协议UDP（user datagram protocol）。TCP协议是一个面向连接的、可靠的协议。它将一台主机发出的字节流无差错地发往互联网上的其他主机。在发送端，它负责把上层传送下来的字节流分成报文段并传递给下层。在接收端，它负责把收到的报文进行重组后递交给上层。TCP协议还要处理端到端的流量控制，以避免缓慢接收的接收方没有足够的缓冲区接收发送方发送的大量数据。UDP协议是一个不可靠的、无连接的协议，主要适用于不需要对报文进行排序和流量控制的场合。TCP/IP模型将OSI参考模型中的会话层和表示层的功能合并到应用层实现。应用层面向不同的网络应用引入了不同的应用层协议。其中，有基于TCP协议的，如文件传输协议（File Transfer Protocol，FTP）、虚拟终端协议（TELNET）、超文本链接协议（Hyper Text Transfer Protocol，HTTP），也有基于UDP协议的。IP协议是TCP/IP协议族中最为核心的协议。它提供不可靠、无连接的服务，也即依赖其他层的协议进行差错控制。在局域网环境，IP协议往往被封装在以太网帧中传送。而所有的TCP、UDP、ICMP、IGMP数据都被封装在IP数据报中传送。IP报文格式：IP头部格式：其中：● 版本（Version）字段：占4比特。用来表明IP协议实现的版本号，当前一般为IPv4，即0100。● 报头长度（Internet Header Length，IHL）字段：占4比特。是头部占32比特的数字，包括可选项。普通IP数据报（没有任何选项），该字段的值是5，即160比特=20字节。此字段最大值为60字节。● 服务类型（Type of Service ，TOS）字段：占8比特。其中前3比特为优先权子字段（Precedence，现已被忽略）。第8比特保留未用。第4至第7比特分别代表延迟、吞吐量、可靠性和花费。当它们取值为1时分别代表要求最小时延、最大吞吐量、最高可靠性和最小费用。这4比特的服务类型中只能置其中1比特为1。可以全为0，若全为0则表示一般服务。● 总长度字段：占16比特。指明整个数据报的长度（以字节为单位）。最大长度为65535字节。● 标志字段：占16比特。用来唯一地标识主机发送的每一份数据报。通常每发一份报文，它的值会加1。● 标志位字段：占3比特。标志一份数据报是否要求分段。● 段偏移字段：占13比特。如果一份数据报要求分段的话，此字段指明该段偏移距原始数据报开始的位置。● 生存期（TTL：Time to Live）字段：占8比特。用来设置数据报最多可以经过的路由器数。由发送数据的源主机设置，通常为32、64、128等。每经过一个路由器，其值减1，直到0时该数据报被丢弃。● 协议字段：占8比特。指明IP层所封装的上层协议类型，如ICMP（1）、IGMP（2） 、TCP（6）、UDP（17）等。● 头部校验和字段：占16比特。内容是根据IP头部计算得到的校验和码。计算方法是：对头部中每个16比特进行二进制反码求和。（和ICMP、IGMP、TCP、UDP不同，IP不对头部后的数据进行校验）。● 源IP地址、目标IP地址字段：各占32比特。用来标明发送IP数据报文的源主机地址和接收IP报文的目标主机地址。可选项字段：占32比特。用来定义一些任选项：如记录路径、时间戳等。这些选项很少被使用，同时并不是所有主机和路由器都支持这些选项。可选项字段的长度必须是32比特的整数倍，如果不足，必须填充0以达到此长度要求。TCP是一种可靠的、面向连接的字节流服务。源主机在传送数据前需要先和目标主机建立连接。然后，在此连接上，被编号的数据段按序收发。同时，要求对每个数据段进行确认，保证了可靠性。如果在指定的时间内没有收到目标主机对所发数据段的确认，源主机将再次发送该数据段。　TCP是一种可靠的、面向连接的字节流服务。源主机在传送数据前需要先和目标主机建立连接。然后，在此连接上，被编号的数据段按序收发。同时，要求对每个数据段进行确认，保证了可靠性。如果在指定的时间内没有收到目标主机对所发数据段的确认，源主机将再次发送该数据段。TCP头部结构：其中：● 源、目标端口号字段：占16比特。TCP协议通过使用"端口"来标识源端和目标端的应用进程。端口号可以使用0到65535之间的任何数字。● 顺序号字段：占32比特。用来标识从TCP源端向TCP目标端发送的数据字节流，它表示在这个报文段中的第一个数据字节。● 确认号字段：占32比特。只有ACK标志为1时，确认号字段才有效。它包含目标端所期望收到源端的下一个数据字节。● 头部长度字段：占4比特。给出头部占32比特的数目。没有任何选项字段的TCP头部长度为20字节；最多可以有60字节的TCP头部。● 标志位字段（U、A、P、R、S、F）：占6比特。各比特的含义如下：◆ URG：紧急指针（urgent pointer）有效。◆ ACK：确认序号有效。◆ PSH：接收方应该尽快将这个报文段交给应用层。◆ RST：重建连接。◆ SYN：发起一个连接。◆ FIN：释放一个连接。● 窗口大小字段：占16比特。此字段用来进行流量控制。单位为字节数，这个值是本机期望一次接收的字节数。● TCP校验和字段：占16比特。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，并由目标端进行验证。● 紧急指针字段：占16比特。它是一个偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。● 选项字段：占32比特。可能包括"窗口扩大因子"、"时间戳"等选项。UDP是一种不可靠的、无连接的数据报服务。源主机在传送数据前不需要和目标主机建立连接。数据被冠以源、目标端口号等UDP报头字段后直接发往目的主机。这时，每个数据段的可靠性依靠上层协议来保证。在传送数据较少、较小的情况下，UDP比TCP更加高效。UDP头部结构：● 源、目标端口号字段：占16比特。作用与TCP数据段中的端口号字段相同，用来标识源端和目标端的应用进程。● 长度字段：占16比特。标明UDP头部和UDP数据的总长度字节。● 校验和字段：占16比特。用来对UDP头部和UDP数据进行校验。和TCP不同的是，对UDP来说，此字段是可选项，而TCP数据段中的校验和字段是必须项。在每个TCP、UDP数据段中都包含源端口和目标端口字段。有时，我们把一个IP地址和一个端口号合称为一个套接字（Socket），而一个套接字对（Socket pair）可以唯一地确定互连网络中每个TCP连接的双方（客户IP地址、客户端口号、服务器IP地址、服务器端口号）。如图所示，是常见的一些协议和它们对应的服务端口号。需要注意的是，不同的应用层协议可能基于不同的传输层协议，如FTP、TELNET、SMTP协议基于可靠的TCP协议。TFTP、SNMP、RIP基于不可靠的UDP协议。同时，有些应用层协议占用了两个不同的端口号，如FTP的20、21端口，SNMP的161、162端口。这些应用层协议在不同的端口提供不同的功能。如FTP的21端口用来侦听用户的连接请求，而20端口用来传送用户的文件数据。再如，SNMP的161端口用于SNMP管理进程获取SNMP代理的数据，而162端口用于SNMP代理主动向SNMP管理进程发送数据。还有一些协议使用了传输层的不同协议提供的服务。如DNS协议同时使用了TCP 53端口和UDP 53端口。DNS协议在UDP的53端口提供域名解析服务，在TCP的53端口提供DNS区域文件传输服务。 来自陈十一

首部固定部分各字段的意义如下： 源端口和目的端口：各占2个字节，分别写入源端口号和目的端口号。序号：占4个字节。序号使用mod运算。TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。故该字段也叫做“报文段序号”。确认序号：占4个字节，是期望收到对方下一个报文段的第一个数据字节的序号。若确认序号=N,则表明：到序号N-1为止的所有数据都已正确收到。数据偏移：占4位，表示TCP报文段的首部长度。注意，“数据偏移”的单位是32位字（即以4字节长的字为计算单位）。故TCP首部的最大长度为60字节。保留：占6位，保留为今后使用，目前置为0；紧急URG：当URG=1，表明紧急指针字段有效。这时发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据。确认ACK：当ACK=1时，确认字段才有效。当ACK=0时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置1。推送PSH：接收方TCP收到PSH=1的报文段，就尽快地交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。复位RST：当RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立运输连接。同步SYN：在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。故SYN置为1，就表示这是一个连接请求和连接接收报文。终止FIN：用来释放连接。当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。窗口：占2个字节。窗口值作为接收方让发送方设置其发送窗口的依据。检验和：占2字节。检验和字段检验的范围包括首部和数据这两部分。和UDP数据报一样，在计算检验和时，也要在TCP报文段的前面加上12字节的伪首部。伪首部的格式与UDP用户数据报的伪首部一样，但要将伪首部第四个字段中的17 改为6（协议号），把第5字段中的UDP长度改为TCP长度。 紧急指针：占2字节。紧急指针仅在URG=1时才有意义，它指出本报文段中的紧急数据的字节数。

本文主要内容1、TCP数据包格式TCP数据包格式如下：注意到中间还有几个标志位：数据包格式当中，最重要的是理解序号和确认序号。TCP为什么是稳定可靠的，与序号与确认序号这套机制紧密相关，这也是TCP的精髓。2、TCP的三次握手众所周知，TCP协议是可靠的，而UDP协议是不可靠的。在一些场景中必须用TCP，比如说用户登录，必须给出明确答复是否登录成功等。而有些场景中，用户是否接收到数据则不那么关键，比如网络游戏当中，玩家射出一颗子弹，另外的玩家是否看到，完全取决于当前网络环境，如果网络卡顿，就会有玩家已经被射杀，但界面仍然刷新不出来的情况。这种情形适合UDP。为了保证TCP协议可靠，在建立连接之时就要得到保证。最初两端的TCP进程都处于CLOSED关闭状态，A主动打开连接，而B被动打开连接。（A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED）B服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。若有，则作出响应。3、TCP的传输和确认TCP 传输的可靠性，可以用一句话归结：每收到对方数据，就发送 ACK 进行确定，发送方发送后没有收到 ACK 就隔一段时间重发。就是 A 向 B 发送消息（下面将 TCP 的报文直接看做是消息，消息一词跟 TCP 报文混用），B 收到消息后需要向 A 发送 ACK。这个 ACK 相当于返回结果，没有返回结果，A 就重新发送消息。归纳起来，A 有 3 种消息需要确认。另外 A 也可以发送 RST 消息，代表出错了。出错消息不需要确认。RST 也可以当成返回接口，替代正常的 ACK。返回 ACK，表示消息发送并处理成功，返回 RST 表示消息处理失败。因为通过网络传输，还有第三种结果，就是不确定成功失败。这样归纳起来。就有三种返回结果。这两种具体情况，A 根本识别不了，都只能重发。4、TCP的序号和确认序号A 向 B 发送消息，假如同时发送 a、b、c、d 消息，因为通过网络，这些消息的顺序并非固定的。而 B 返回 ACK 结果，这样就有一个问题，这个结果到底对应了哪个消息？另外当 A 超时重发后，原来的消息延时一段时候，又重新到达了 B，这样 B 就收到两条相同的消息，那么 B 怎么确定这两条消息是相同的呢？为了解决这个对应问题，每一条消息都需要有一个编号，返回结果也应该有一个编号。TCP 的序号可以看成是发送消息的编号，确认序号可以看成是返回结果的编号。有了编号，重复的消息才可以忽略，返回结果(ACK)才可以跟消息对应起来。当建立连接的时候，TCP 选定一个初始序号，之后每发送一个数据包（消息），就将序号递增，保证每发送不同的数据包，数据包的序号都是不同的。TCP 是这样处理的：SYN、FIN 也需要递增序号。不然 A 向 B 重发多个 SYN 或者 FIN, B 根本判断不了 SYN 是否相同，这样就不可以忽略重复的数据包了。当 TCP 发送 ACK 时，相当于返回结果，需要带有确认序号，以便跟发送的消息对应起来。当发送包编号为 a，递增长度为 len。其中 SYN 和 FIN 可以看成是递增长度为 1。这条消息可以这样表示为：现在来回顾三次握手过程。 A 发送序列号x给 B ， B 回复 A 确认号 x+ 1，同时发送序列号 y， A 接收到 B 的回复后，再回复确认号 y+1，同时发送序列号 x+1。给对方的回复一定是接收到的序号加1（或者是数据长度），这样对方才能知道我已经收到了，这样才能保证TCP是可靠的。

计算机网络七层模型中，传输层有两个重要的协议：（1）用户数据报协议UDP (User Datagram Protocol)（2）传输控制协议TCP (Transmission Control Protocol)UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP 报文后，不需要给出任何确认。虽然UDP 不提供可靠交付，但在某些情况下UDP 却是一种最有效的工作方式。TCP 则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。UDP 的主要特点是：首部手段很简单，只有8 个字节，由四个字段组成，每个字段的长度都是两个字节。前面已经讲过，每条TCP 连接有两个端点，TCP 连接的端点叫做套接字（socket）或插口。套接字格式如下：套接宁socket= (IP 地址：端口号’）每一条TCP 连接唯一地被通信两端的两个端点（即两个套接宇）所确定。即：TCP 连接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}3次握手链接4次握手释放链接断开连接请求可以由客户端发出，也可以由服务器端发出，在这里我们称A端向B端请求断开连接。各个状态节点解释如下：下面为了讨论问题的万便，我们仅考虑A发送数据而B 接收数据并发送确认。因此A 叫做发送方，而B 叫做接收方。“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest）。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。滑动窗口协议比较复杂，是TCP 协议的精髓所在。这里先给出连续ARQ 协议最基本的概念，但不涉提到许多细节问题。详细的滑动窗口协议将在后面讨论。下图表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5 个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。连续ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都己正确收到了。累积确认的优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。例如，如果发送方发送了前5 个分组，而中间的第3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N （回退N ），表示需要再退回来重传己发送过的N 个分组。可见当通信线路质量不好时，连续ARQ 协议会带来负面的影响。TCP 的滑动窗口是以字节为单位的。现假定A 收到了B 发来的确认报文段，其中窗口是20 （字节），而确认号是31 （这表明B 期望收到的下一个序号是31 ，而序号30 为止的数据己经收到了）。根据这两个数据， A 就构造出自己的发送窗口，其位置如图所示。发送窗口表示：在没有收到B 的确认的情况下， A可以连续把窗口内的数据都发送出去。凡是己经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。发送窗口后沿的后面部分表示己发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。现在假定A 发送了序号为31 ～ 41 的数据。这时发送窗口位置并未改变，但发送窗口内靠后面有11个字节（灰色小方框表示）表示己发送但未收到确认。而发送窗口内靠前面的9 个字节（ 42 ～ 50 ）是允许发送但尚未发送的。】再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 号为止的数据是已经发送过确认，并且己经交付给主机了。因此在B 可以不再保留这些数据。接收窗口内的序号（31～50）足允许接收的。B 收到了序号为32 和33 的数据，这些数据没有按序到达，因为序号为31 的数据没有收到（也许丢失了，也许滞留在网络中的某处）。请注意， B 只能对按序收到的数据中的最高序号给出确认，因此B 发送的确认报文段中的确认号仍然是31 （即期望收到的序号）。现在假定B 收到了序号为31 的数据，并把序号为31～33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A 发送确认，其中窗口值仍为20，但确认号是34，这表明B 已经收到了到序号33 为止的数据。我们注意到，B还收到了序号为37, 38 和40 的数据，但这些都没有按序到达，只能先存在接收窗口。A收到B的确认后，就可以把发送窗口向前滑动3个序号，指针P2 不动。可以看出，现在A 的可用窗口增大了，可发送的序号范围是42～53。整个过程如下图：A 在继续发送完序号42-53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认。由于A 的发送窗口己满，可用窗口己减小到0，因此必须停止发送。上面已经讲到， TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP 最复杂的问题之一。TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT，TCP 保留了RTT的一个加权平均往返时间RTTs （这又称为平滑的往返时间， S 表示Smoothed 。因为进行的是加权平均，因此得出的结果更加平滑）。每当第一次测量到RTT样本时， RTTs值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTTs:新的RTTs = (1 － α）×（旧的RTTs) ＋ α ×（新的RTT样本）α 越大表示新的RTTs受新的RTT样本的影响越大。推荐的α 值为0.125，用这种方法得出的加权平均往返时间RTTs 就比测量出的RTT值更加平滑。显然，超时计时器设置的超时重传时间RTO (RetransmissionTime-Out）应略大于上面得出的加权平均往返时间RTTs。RFC 2988 建议使用下式计算RTO:RTO = RTTs + 4 × RTTdRTTd是RTT 的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。计算公式如下：新的RTTd= (1- β）×（旧的RTTd) + β × |RTTs－新的RTT样本|发现问题：如图所示，发送出一个报文段。设定的重传时间到了，还没有收到确认。于是重传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？若收到的确认是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的RTTs 和超时重传时间RTO 就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间RTO 就越来越长。若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则由此计算出的RTTs 和RTO 都会偏小。这就必然导致报文段过多地重传。这样就有可能使RTO 越来越短。Kam 提出了一个算法：在计算加权平均RTTs 时，只要报文段重传了就不采用其往返时间样本。这样得出的加权平均RTTs 和RTO 就较准确。新问题：设想出现这样的情况：报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Kam 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。解决方案：对Kam 算法进行修正，方法是z报文段每重传一次，就把超时重传时间RTO 增大一些。典型的做法是取新的重传时间为2 倍的旧的重传时间。当不再发生报文段的重传时，才根据上面给出的公式计算超时重传时间。流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口机制可以很方便地在TCP 连接上实现对发送方的流量控制。接收方的主机B 进行了三次流量控制。第一次把窗口减小到rwnd =300，第二次又减到rwnd = 100 ，最后减到rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B 重新发出一个新的窗口值为止。我们还应注意到，B 向A 发送的三个报文段都设置了ACK=1，只有在ACK=1 时确认号字段才有意义。发生死锁：现在我们考虑一种情况。上图中， B 向A 发送了零窗口的报文段后不久， B 的接收缓存又有了一些存储空间。于是B 向A 发送了rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。A 一直等待收到B 发送的非零窗口的通知，而B 也一直等待A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。解决方案：TCP 为每一个连接设有一个持续计时器（persistence timer）。只要TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1 宇节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。1 TCP连接时是三次握手，那么两次握手可行吗？在《计算机网络》中是这样解释的：已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。这样就会白白浪费资源。而经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。2 为什么TCP连接是三次，挥手确是四次？在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中，B端向A端发送的ACK和FIN是是分两次发送的。因为在B端接收到A端的FIN后，B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。3 为什么在第四次挥手后会有2个MSL的延时？MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。假定网络不可靠，那么第四次发送的ACK可能丢失，即B端无法收到这个ACK，如果B端收不到这个确认ACK，B端会定时向A端重复发送FIN，直到B端收到A的确认ACK。所以这个2MSL就是用来处理这个可能丢失的ACK的。1 文件传送协议文件传送协议FTP (File Transfer Protocol) [RFC 959］是因特网上使用得最广泛的文件传送协议，底层采用TCP协议。盯P 使用客户服务器方式。一个FTP 服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成：一个主进程，负责接受新的请求：另外有若干个从属进程，负责处理单个请求。在进行文件传输时，客户和服务器之间要建立两个并行的TCP 连接：“控制连接”（21端口）和“数据连接”（22端口）。控制连接在整个会话期间一直保持打开， FTP 客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用于传输文件的是“数据连接”。服务器端的控制进程在接收到FTP 客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”，用来连接客户端和服务器端的数据传送进程。2 简单文件传送协议TFTPTCP/IP 协议族中还有一个简单文件传送协议TFfP (Trivial File Transfer Protocol），它是一个很小且易于实现的文件传送协议，端口号69。TFfP 也使用客户服务器方式，但它使用UDP 数据报，因此TFfP 需要有自己的差错改正措施。TFfP 只支持文件传输而不支持交耳。3 TELNETTELNET 是一个简单的远程终端协议，底层采用TCP协议。TELNET 也使用客户服务器方式。在本地系统运行TELNET 客户进程，而在远地主机则运行TELNET 服务器进程，占用端口23。4 邮件传输协议一个电子邮件系统应具如图所示的三个主要组成构件，这就是用户代理、邮件服务器，以及邮件发送协议（如SMTP ）和邮件读取协议（如POP3)， POP3 是邮局协议（Post Office Protocol）的版本3 。SMTP 和POP3 （或IMAP ）都是在TCP 连接的上面传送邮件，使用TCP 的目的是为了使邮件的传送成为可靠的。