端口号调研、URG和PSH、及TCP的计时器

端口号

端口号是用来标识目的主机当中的唯一网络进程，因此IP地址+端口号=》套接字；套接字可以确定唯一的一个进程。

Tcp/Ip协议中引入一种叫做“套接字”的应用程序软件，有了这样一种技术，一台电脑就可以与任意一台具有套接字的电脑通信。

端口的分类：

从性质来分：
1）公认端口：0—1024，紧密绑定一些特定的服务，这类端口不可重新定义它的作用对象，例如80号端口对应http，23号端口对应Telnet服务
2）注册端口：1025-49151，这些端口多数没有明确的定义服务对象，不同程序可以根据实际需要自己定义，
3）动态和/或私有端口：49152-65535，不应把常用服务分配在这些端口上，一些木马程序非常喜欢用这些端口；

根据所提供的服务方式不同可以分为TCP相关端口和UDP相关端口；

TCP类的有：
1）FTP：21号文件传输端口；下载文件，上传主页；
2）Telnet:23远程登陆端口，用户可以以自己的身份远程登陆到电脑上，通过这种端口可以提供一种Dos服务下的通信模式；
3）SMTP：25简单邮件传送协议；
4）POP3：110端口，和SMTP类似，用于接受邮件；

UDP类的有：
1）HTTP:80号超文本传输协议，常用的“WWW服务”，“web服务”就是这个端口
2）DNS：53号，域名解析服务；
3）SNMP：161号，简单网络管理协议；
4）OICQ:既接收服务又提供服务；OICQ服务器采用8000号端口，倾听是否有信息到来，OICQ则采用4000号端口，向外发送信息；

URG和PSH

1、URG推送位

紧急数据的起始点=序号；
紧急数据的终止点=序号+紧急指针；

（综上，紧急指针就是记录紧急数据的字节数，紧急指针永远为正数）

1）在紧急数据后面的数据为普通数据，需要按序缓存
2）窗口为0也可以发送紧急数据
3）紧急数据都处理完成后，tcp就告诉进程恢复到正常操作
例如，已经发送了很长的一个程序要在远地的主机上运行。但后来发现了一些问题，需要取消程序的运行。因此用户从键盘发出中断命令（Ctrl+C）。如果不使用紧急数据，那么这两个字符会被存储在接受TCP的缓存末尾。只有在所有的数据被处理完毕后这两个字符才会被交付给接收方。这样就浪费了很多时间。

URG强调的是直接读取数据,我们不会将该数据复制到缓存中,我个人认为,这个数据(紧急指针指向的数据)并不是真正意义上的”数据”,而是对真正意义上”数据”的一种操作.

2、PSH推送位

PSH=1，该报文希望，到达对端时，将这个报文及缓存区之间缓存尚未交付的数据一并交付给进程。
1)PSH的数据=本报文数据+缓存区数据
2)PSH的方向—>单方向（接收PSH报文的一端）

PSH强调的是尽快将数据交付给上层(协议),而不需要经过强迫数据交互(默认tcp/ip是将数据缓存到一定的上限,再将数据递交给上层,以提高网络性能).可见,该部分数据是需要复制到缓存中的

3、区别

URG交付给进程的数据：只有紧急数据

PSH交付给进程的数据：缓冲区排好序的数据及当前报文中的数据
两者的共同点：都是一种对数据的处理方式.只不过URG是处理在前端(收到数据后立马对真正意义上”数据”进行操作,所以说”紧急.而PSH是在处理的后端,告诉内核,不用等待”满了”再递交数据递交到上层.

TCP的计时器

TCP使用四种定时器(Timer，也称为“计时器”)：
重传计时器：Retransmission Timer
坚持计时器：Persistent Timer
保活计时器：Keeplive Timer
时间等待计时器：Time_Wait Timer。

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报文段在到达终点后被丢弃，这个计时器的值通常设置为一格报文段寿命期望值的两倍。