唯一确定tcp连接端点的是(唯一确定一条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 的目的是为了使邮件的传送成为可靠的。

TCP/IP唯一性含除地址和端口外还有一个时间上的标记才可完全确立。 对TCP而言在三次握手时的SYN标志会使用上一个ISN值，这个值是使用32位计数器，由0-4294967295，每一次连接都会分配到一个ISN值，连接双方对这个值会记录共识，假如这个值不一，就说明了这个连接已超时或无效甚至是被人恶意攻击冒充连接。
是由一个四元组唯一确定的，包括本地IP,本地端口，远程IP,远程IP,远程端口。
FamDestiny的回答，最好在加上一个时间，这样 肯定是唯一的。
ip地址端口地址物理地址

UDP包 UDP报头由4个域组成，其中每个域各占用2个字节，具体如下：源端口号目标端口号数据报长度校验值UDP协议使用端口号为不同的应用保留其各自的数据传输通道。UDP和TCP协议正是采用这一机制实现对同一时刻内多项应用同时发送和接收数据的支持。数据发送一方（可以是客户端或服务器端）将UDP数据报通过源端口发送出去，而数据接收一方则通过目标端口接收数据。有的网络应用只能使用预先为其预留或注册的静态端口；而另外一些网络应用则可以使用未被注册的动态端口。因为UDP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。一般来说，大于49151的端口号都代表动态端口。TCP包每个tcp都包含源端口号和目标端口号，加上ip头中的源ip和目的ip，唯一确定一个tcp连接。序号用来标识从tcp发端向tcp收端发送的数据字节流，它表示在这个报文段中的第一个数据字节。序号字段包含由这个主机选择的该连接的初始序号isn（Initial Sequence Number）。该主机要发送数据的第一个字节，序号为isn+1，因为syn占用了一个序号。IP包IPV4报头有12个必需的字段和可选IP选项字段，位于要发送的数据之前。如果使用IP层已有的库或其他组件，一般不必考虑报头中的大多数字段，但程序代码需要提供源端和目的端地址。1、版本（4比特）IP协议版本已经经过多次修订，1981年的RFC0791描述了IPV4，RCF2460中介绍了IPV6。2、报头长度（4比特）报头长度是报头数据的长度，以4字节表示，也就是以32字节为单位。报头长度是可变的。必需的字段使用20字节（报头长度为5，IP选项字段最多有40个附加字节（报头长度为15）。3、服务类型（8比特）该字段给出发送进程建议路由器如何处理报片的方法。可选择最大可靠性、最小延迟、最大吞吐量和最小开销。路由器可以忽略这部分。4、数据报长度（16比特）该字段是报头长度和数据字节的总和，以字节为单位。最大长度为65535字节。5、标识符（16比特）原是数据的主机为数据报分配一个唯一的数据报标识符。在数据报传向目的地址时，如果路由器将数据报分为报片，那么每个报片都有相同的数据标识符。6、标志（3比特）标志字段中有2为与报片有关。位0：未用。位1：不是报片。如果这位是1，则路由器就不会把数据报分片。路由器会尽可能把数据报传给可一次接收整个数据报的网络；否则，路由器会放弃数据报，并返回 差错报文，表示目的地址不可达。IP标准要求主机可以接收576字节以内的数据报，因此，如果想把数据报传给未知的主机，并想确认数据报没有因为大小的原 因而被放弃，那么就使用少于或等于576字节的数据。位2：更多的报片。如果该位为1，则数据报是一个报片，但不是该分片数据报的最后一个报片；如果该位为0，则数据报没有分片，或者是最后一个报片。7、报片偏移（13比特）该字段标识报片在分片数据报中的位置。其值以8字节为单位，最大为8191字节，对应65528字节的偏移。例如，将要发送的1024字节分为576和424字节两个报片。首片的偏移是0，第二片的偏移是72（因为72×8＝576）。8、生存时间（8比特）如果数据报在合理时间内没有到达目的地，则网络就会放弃它。生存时间字段确定放弃数据报的时间。生存时间表示数据报剩余的时间，每个路由器都会将其值减一，或递减需要数理和传递数据报的时间。实际上，路由器处理和传递数据报的时间一般都小于1S，因此该值没有测量时间，而是测量路由器之间跳跃次数或网段的个数。发送数据报的计算机设置初始生存时间。9、协议（8比特）该字段指定数据报的数据部分所使用的协议，因此IP层知道将接收到的数据报传向何处。TCP协议为6，UDP协议为17。10、报头检验和（16比特）该字端使数据报的接收方只需要检验IP报头中的错误，而不校验数据区的内容或报文。校验和由报头中的数值计算而得，报头校验和假设为0，以太网帧和TCP报文段以及UDP数据报中的可选项都需要进行报文检错。11、源IP地址（32比特）表示数据报的发送方。12、目的IP地址（32比特） 表示数据报的目的地。
TCP报文段首部（20个字节） 源端口和目标端口：各占2个字节，16比特的端标语加上32比特的IP地址，共同构成相当于传输层办事接见点的地址，即“插口”；这些端口可用来将若干高层和谈向下复用；序号字段和确认序号字段：序号：占4个字节，是本报文段所发送的数据项目组第一个字节的序号。在TCP传送的数据流中，每一个字节都有一个序号。例如，一报文段的序号为300，而起数据供100字节，则下一个报文段的序号就是400；确认序号：占4字节，是期望收到对方下次发送的数据的第一个字节的序号，也就是期望收到的下一个报文段的首部中的序号；因为序号字段有32比特长，可以对4GB的数据进行编号，如许就可包管当序号反复应用时，旧序号的数据早已在收集中消散了；数据偏移字段数据偏移：占4比特，默示数据开端的处所离TCP报文段的肇端处有多远。这实际上就是TCP报文段首部的长度。因为首部长度不固定，是以数据偏移字段是须要的。保存字段： 6比特，供往后应用，今朝置为0。6个比特的把握字段紧急比特URGent：当URG=1时，注解此报文应尽快传送，而不要按本来的列队次序来传送。与“紧急指针”字段共同应用，紧急指针指出在本报文段中的紧急数据的最后一个字节的序号，使接管方可以知道紧急数据共有多长；确认比特ACK：只有当ACK=1时，确认序号字段才有意义；急迫比特PSH：当PSH=1时，注解恳求远地TCP将本报文段立即传送给其应用层，而不要比及全部缓存都填满了之后再向上交付。复位比特ReSeT：当RST=1时，注解呈现严重错误，必须开释连接，然后再重建传输连接。复位比特还用来拒绝一个不法的报文段或拒绝打开一个连接；同步比特SYN：在建树连接时应用，当SYN=1而ACK=0时，注解这是一个连接恳求报文段。对方若赞成建树连接，在发还的报文段中使SYN=1和ACK=1。是以，SYN=1默示这是一个连接恳求或毗邻接管报文，而ACK的值用来区分是哪一种报文；终止比特FINal：用来开释一个连接，当FIN=1时，注解欲发送的字节串已经发完，并请求开释传输连接；窗口字段窗口Window：占2字节，默示报文段发送方的接管窗口，单位为字节。此窗口告诉对方，“在未收到我的确认时，你可以或许发送的数据的字节数至多是此窗口的大小。”通知窗口advertised window：接管端按照其接管才能承诺的窗口值，是来自接管端的流量把握。接管端将通知窗口的值放在TCP报文的首部中，传送给对方。拥塞窗口congestion window：是发送端按照收集拥塞景象得出的窗口值，是来自发送端的流量把握。查验和覆盖了全部的TCP报文段：TCP首部和TCP数据。这是一个强迫性的字段，由发端策画和存储，由收端进行验证。选项字段容许每台主机设定可以或许接管的最大TCP载荷才能（缺省536字节） 。TCP的数据编号与确认数据流、报文段和序号TCP通信的动作切割：按照合适传输的大小对数据流进行切割最大报文段长度<64Kbytes凡是：MTU－（IP头＋TCP头）答复复兴：用报文段恢答复复兴始数据流的字节次序序号：排序、查错及数据流答复复兴报文序号根据数据流中的字节序号（流序号）报文序号为报文段中第一字节的流序号如：流序号＝x，长度＝L的报文段，则：报文的序号为x，下一报文序号为x＋L序号特点报文的次序关系数据流的地位，更便于流的答复复兴需较大的序号空间（32bit，4Gbyte）例如：在一个报文中，序号为300，而报文中数占领100字节。下一个报文符，其序号为400；UDP报文结构：UDP报文比较简单，由四个字段组成，每个字段2个字节：(1) 源端口 source port(2) 目的端口 destination port(3) 长度 :UDP用户数据报的长度(4) 检验和checksumUDP与TCP比较：相同点：§同一层的协议，基于IP报文基础上不同点：TCP是可靠的，高可用性的协议，但是复杂，需要大量资源的开销 UDP是不可靠，但是高效的传输协议

在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协议最基本的概念，但不涉及到许多细节问题。位于发送窗口的分组都可以连续的发送出去，而不需要等待对方的确认，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。详细可以见P201TCP虽然是面向字节流的，但是TCP传送的数据单元却是报文段（可以看上述TCP面向流的概念），而且TCP的全部功能都体现在它的首部中各个字段。详解请见P206，注意图中的后沿，前沿从下图可以看出来，要描述一个发送窗口的状态需要三个指针：P1，P2，P3有很多信息见P208，这里不赘述发送方的应用进程把字节流写入TCP的发送缓存，接收方的应用进程从TCP的接收缓存中读取字节流。下面进一步讨论前面讲的窗口和缓存的关系发送缓存发送窗口通常只是发送缓存的一部分，已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中被写入的字节。发送应用程序必须控制写入缓存的速率，不能太快 ，否则发送缓存就会没有存放数据的空间。如果收到的分组被检测出有差错，则要丢弃。如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减少到零。反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收缓存的大小。TCP才用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。TCP 保留了 RTT 的一个加权平均往返时间 RTTs（这又称为平滑（smooth）的往返时间，因为是加权平均，所以是平滑的）。第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS：显然，RTO 应略大于上面得出的加权平均往返时间 RTTsRFC 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 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。下面的执行步骤就是按照折现上的点的顺序

TCP/IP唯一性含除地址和端口外还有一个时间上的标记才可完全确立。 对TCP而言在三次握手时的SYN标志会使用上一个ISN值，这个值是使用32位计数器，由0-4294967295，每一次连接都会分配到一个ISN值，连接双方对这个值会记录共识，假如这个值不一，就说明了这个连接已超时或无效甚至是被人恶意攻击冒充连接。