在启动滑动视窗之后﹐封包的传送看起来如下图﹕
　　　
　　滑动视窗会记住哪些封包已经被确认﹐并且为每一个未被确认的封包保留各自的计时器。如果在逾时后还没得到该封包的确认﹐则重发该封包。发送端在移动视窗的时候﹐它会移过所有已确认的封包。在视窗中﹐编号最低的封包﹐往往是序列中的第一个未被确认的封包。
　　通讯埠口(port)
　　大多数的作业系统都提供多工环境﹐允许多个应用程式同时执行﹐在系统术语里面﹐我们管每一个程式的起止为一个行程。每一个行程都是动态产生的﹐发送端无法预知接收端的某一个行程的实际状况如何。那么﹐当一个封包抵达目的地之后﹐接收如何将封包交给正确的行程处理呢﹖
　　在传送层协定里面﹐我们为程式产生的行程分配一个通讯埠口﹐其值为一个正正数。当一个应用程式需要建立网路连线的时候﹐传送层协定就为该应用程式产生的行程建立一个埠口。而事实上，所谓的网路连线，就是两个通讯埠口之间的连线。关于网路通讯模式的建立有两种﹕
　　· 主动连线
　　· 被动连线
　　主动连线是当埠口建立之后﹐行程透过该埠口主动发出连线的要求﹔被动模式则是﹐当埠口建立之后﹐行程在该埠口等待连线的请求。在 client/server 的架构之下，连线的建立顺序通常是伺服器端先建立好被动连线﹐然后等待客户端的主动连线。
　　在技术上﹐行程使用哪一个埠口并不重要﹐关键是能让对方知道埠口是哪一个就行。我们可以把 IP 位址看成主机的门牌号码﹐而埠口则是服务柜台。在多工的环境下﹐行程会在一个门牌上面开启多个柜台。您或许会问：由起始端主动发起之连线封包抵达之后﹐它究竟凭什么来判断究竟哪个柜台才是正确的行程呢？在日常的生活中﹐大不了逐个柜台去问... 然而在网路系统上面﹐这个似乎有点不切实际。因为﹐每一个埠口的建立和关闭都是随机的﹐在不同的时段里﹐所开启的埠口数目和号码都不尽相同。既然如此﹐等待连线那端何不先将接收行程所使用埠口号码告知起始端呢？但问题是：既然连线要由起始端主动建立才能连上等待端﹐在没有真正连上之前如何得知呢？不是鸡生蛋、蛋生鸡的问题吗？
　　有见及此﹐在网际网路的实作应用中﹐人们将一些常用的服务程式所使用埠口号码固定起来。例如﹕21 给 FTP 服务使用﹑23 给 TELNET 服务使用﹑25 给 SMTP 服务使用... 我们称这样的埠口为 Well-Known Port。在伺服器端﹐这些常用服务会先行建立好被动连线﹐打开所分配的埠口﹐以等待起始端的连线请求。那么﹐起始端只要在封包填上目的端的埠口值﹐接收端就能将封包传给正确的服务了， 这也就是透过约定俗成的分配来建立连线。但事实上，您大可架设一个地下网站，故意使用其它非 Well-Known Port 来建立被动连线埠口，这样，只有那些事先被告知埠口值、且能修改主动连线设定的客户端才知门而入了。