1.端口号
（1）.基本概念：端口包括物理端口和逻辑端口。物理端口是用于连接物理设备之间的接口，逻辑端口是逻辑上用于区分服务的端口。TCP/IP协议中的端口就是逻辑端口，通过不同的逻辑端口来区分不同的服务。一个IP地址的端口通过16bit进行编号，最多可以有65536个端口。端口是通过端口号来标记的，端口号只有整数，范围是从0 到65535。
（2）.如何对端口号进行分类
1. 服务器端使用的端口号有分为两类：
<1>熟知端口号（系统端口号），数值为0~1023，IANA把这些端口号指派给TCP/IP最重要的一些应用程序，让所有的用户都知道。当一些新的应用程序出现后，IANA必须为他指派一个熟知端口号，否则英特网上的其他应用进程就无法和他通信。下面为一些常见的熟知端口号。
<2>登记端口号，数值为1024~49151，这类端口号是为没有熟知端口号的应用程序使用的。使用这类端口号必须在IANA按照规定的手续登记，以防止重复
2. 客户端使用的端口号，数字为49152~65535,这类端口号是留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的端口号，因此我们可以把数据发送给客户进程。通信结束后，刚才已使用过的客户端口号就不复存在了。这个端口号就可以供其他客户进程以后使用。
URG（紧急位）: 急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。紧急指针指向包内数据段的某个字节(数据从第一字节到指针所指字节就是紧急数据,不进入接收缓冲就直接交给上层进程,余下的数据要进入接收缓冲的)
PSH（急迫位）: 在一个交互程序中，当客户发送一个命令给服务器时，它设置PSH标志并停下来等待服务器的响应。通过允许客户应用程序通知其TCP设置PSH标志，客户进程通知TCP在向服务器发送一个报文段时不要因等待额外数据而使已提交数据在缓存中滞留。类似地，当服务器的TCP接收到一个设置了PSH标志的报文段时，它需要立即将这些数据（包括以前存中滞留的数据）递交给服务器进程而不能等待判断是否还会有额外的数据到达。 PSH=1,只对接收方的接收缓冲区起作用，发送方通过使用PSH位来通知接收方将所有收到的数据立即提交给服务器进程，而不需要等待额外数据(将缓存填满)而让数据在缓存中停留！这里所说的数据包括与此PSH包一起传输的数据以及之前就为该进程传输过来的数据（滞留在缓存中的数据）。
TCP常见定时器
(1)重传计时器：Retransmission Timer
重传定时器：为了控制丢失的报文段或丢弃的报文段，也就是对报文段确认的等待时间。当TCP发送报文段时，就创建这个特定报文段的重传计时器，可能发生两种情况：若在计时器超时之前收到对报文段的确认，则撤销计时器;若在收到对特定报文段的确认之前计时器超时，则重传该报文，并把计时器复位;重传时间=2*RTT;
RTT的值应该动态计算。常用的公式是：RTT=previous RTT*i + (1-i)*current RTT。i的值通常取90%，即新的RTT是以前的RTT值的90%加上当前RTT值的10%.
Karn算法：对重传报文，在计算新的RTT时，不考虑重传报文的RTT。因为无法推理出：发送端所收到的确认是对上一次报文段的确认还是对重传报文段的确认。干脆不计入。
(2)坚持计时器：persistent timer
专门为对付零窗口通知而设立的。
当发送端收到零窗口的确认时，就启动坚持计时器，当坚持计时器截止期到时，发送端TCP就发送一个特殊的报文段，叫探测报文段，这个报文段只有一个字节的数据。探测报文段有序号，但序号永远不需要确认，甚至在计算对其他部分数据的确认时这个序号也被忽略。探测报文段提醒接收端TCP，确认已丢失，必须重传。
坚持计时器的截止期设置为重传时间的值，但若没有收到从接收端来的响应，则发送另一个探测报文段，并将坚持计时器的值加倍和并复位，发送端继续发送探测报文段，将坚持计时器的值加倍和复位，知道这个值增大到阈值为止(通常为60秒)。之后，发送端每隔60s就发送一个报文段，直到窗口重新打开为止;补充：
坚持定时器的原理是简单的，当TCP服务器收到了客户端的0滑动窗口报文的时候，就启动一个定时器来计时，并在定时器溢出的时候向向客户端查询窗口是否已经增大，如果得到非零的窗口就重新开始发送数据，如果得到0窗口就再开一个新的定时器准备下一次查询。通过观察可以得知，TCP的坚持定时器使用1，2，4，8，16……64秒这样的普通指数退避序列来作为每一次的溢出时间。
糊涂窗口综合症
TCP的窗口协议，会引起一种通常叫做糊涂窗口综合症的问题，具体表现为，当客户端通告一个小的非零窗口时，服务器立刻发送小数据给客户端并充满其缓冲区，一来二去就会让网络中充满小TCP数据报，从而影响网络利用率。对于发送方和接收端的这种糊涂行为。
再次补充：
TCP通过让接收方指明希望从发送方接收的数据字节数(即窗口大小)来进行流量控制。如果窗口大小为 0会发生什么情况呢?这将有效地阻止发送方传送数据，直到窗口变为非0为止。
TCP不对ACK报文段进行确认， TCP只确认那些包含有数据的ACK报文段。
如果一个确认丢失了(这个确认是”接收方“向”发送方“发送的ACK，通知”发送方“自己的窗口已经非0了)，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据(因为它已经向发送方通告了一个非 0的窗口)，而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。
(3)保活计时器：keeplive timer
每当服务器收到客户的信息，就将keeplive timer复位，超时通常设置2小时，若服务器超过2小时还没有收到来自客户的信息，就发送探测报文段，若发送了10个探测报文段(没75秒发送一个)还没收到响应，则终止连接。
补充：
保活定时器更加的简单，还记得FTP或者Http服务器都有Sesstion Time机制么?因为TCP是面向连接的，所以就会出现只连接不传送数据的“半开放连接”，服务器当然要检测到这种连接并且在某些情况下释放这种连接，这就是保活定时器的作用。其时限根据服务器的实现不同而不通。另外要提到的是，当其中一端如果崩溃并重新启动的情况下，如果收到该端“前生”的保活探察，则要发送一个RST数据报文帮助另一端结束连接。
(4)时间等待计时器：Time_Wait Timer
在连接终止期使用，当TCP关闭连接时，并不认为这个连接就真正关闭了，在时间等待期间，连接还处于一种中间过度状态。这样就可以时重复的fin报文段在到达终点后被丢弃，这个计时器的值通常设置为一格报文段寿命期望值的两倍。
补充：
2MSL定时器：MSL是报文段做大生存时间(Maximum Segment Lifetime),设置这个定时器有两个目的：
其一是为了测量连接处于TIME_WAIT状态的时间.这样可以让TCP再次发送最后的ACK以防止这个ACK丢失(如果丢失，另一端会重传FIN)。
其二，为允许老的重复分节在网络中消逝。具体可以解释为，如果一个TCP连接在断开之前有迷途分节尚未消逝，在断开该TCP连接之后立刻重启一个同样的连接(双方的IP地址和端口port相同)，这时之前的迷途的老分节可能对新的新的TCP连接接收，从而造成未定义的错误。为了避免这种情况，TCP规定在TIME_WAIT状态，不能启动一个连接的化身。既然TIME_WAIT状态维持2MSL，这就保证了一个连接上的分组及其应该在 2MSL内都会消失。
TCP三次握手与四次挥手
为什么需要“三次握手”
“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。另一种“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不用的表述其实阐明的是同一个问题。
谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源
为什么需要“四次”挥手
那可能有人会有疑问，在tcp连接握手时为何ACK是和SYN一起发送，这里ACK却没有和FIN一起发送呢。原因是因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送。
四次挥手的自动发起者断开连接将处于TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。
234
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
