端口/URG＆PSH/TCP定时器/TCP的三次握手及四次挥手

一、网络端口 

有效端口个数 

        在进行各个主机之间进行通信的时候我们需要将某些数据进程传输，这个时候就需要将数据传入到某一个特定的主机，即使用TCP/IP协议，IP地址可以用来标识唯一的一台主机，端口号用来标识目标主机上唯一的一个网络进程，IP地址与端口号拼接在一起形成套接字就可以标识互联网中的唯一进程。

         一共有65535个端口，其中0–1023是系统保留的，1024–65535是供用户使用的。0到1024是众所周知的端口（知名端口，常用于系统服务等，例如http服务的端口号是80。一般作为网络服务器使用，服务器必须是一个非常明确的端口号，并且永远不能改变，所以服务器端口号一般是众所周知的)。个人写的应用程序，尽量不要使用0到1024之间的端口号。而之后的客户端的端口号是由用户去指定的，可以随机去改变。

 端口分类

 1.按端口号划分

（1）公认端口（Well Known Ports） 0~1023，它们紧密绑定于一些服务，通常这些端口的通讯明确表明了某种服务的协议，如：80端口对应与HTTP通信，21端口绑定与FTP服务，25端口绑定于SMTP服务，135端口绑定与RPC（远程过程调用）服务。

（2）注册端口（Registered Ports） 1024~49151，它们松散的绑定于一些服务，也就是说有许多服务绑定于这些端口，这些端口同样用于其他许多目的，如：许多系统处理端口从1024开始 - 动态和/或私有端口（Dyanmicand /or Private Ports） 49152~65535，理论上，不应为服务分配这些端口，通常机器从1024开始分配动态端口。例外：SUN的RPC端口从32768开始。

 2.按协议类型划分按协议类型划分可分为TCP端口、UDP端口、IP端口、ICMP（Internet控制消息协议）。

 TCP端口：即传输控制协议端口，需要在客户端和服务器之间建立连接，这样可以提供可靠的数据传输。常见的包括FTP的21端口，Telnet的23端口，SMTP的25端口，HTTP的80端口。

 UDP端口：即用户数据报协议端口，无需在客户端和服务器端建立连接，安全性得不到保障。常见的DNS的53端口，SNMP（简单网络管理协议）的161端口，QQ使用的8000和4000端口。

 保留端口： UNIX有保留端口号的概念，只有超级用户特权的进程才允许给它自己分配一个保留端口号。这些端口号介于1~1023之间，一些应用程序将它作为客户与服务器认证的一部分。

 网络服务常用端口号： 

21/tcp FTP 文件传输协议 

22/tcp SSH 安全登录、文件传送(SCP)和端口重定向 

23/tcp Telnet 不安全的文本传送 

25/tcp SMTP Simple Mail Transfer Protocol (E-mail) 

69/udp TFTP Trivial File Transfer Protocol 79/tcp finger Finger 

80/tcp HTTP 超文本传送协议 (WWW) 

88/tcp Kerberos Authenticating agent 

110/tcp POP3 Post Office Protocol (E-mail) 

113/tcp ident old identification server system 

119/tcp NNTP used for usenet newsgroups 

220/tcp IMAP3 

443/tcp HTTPS used for securely transferring web pages

 二、URG&PSH 

URG：紧急指针（紧急位）。当URG=1时，tcp报文为紧急报文，其中的数据直接交给接收端的进程，不进入缓存区（紧急数据为从第一个字节到紧急指针所指的字节）。在紧急数据之后的数据依旧为普通数据，要按序进入缓存；即便窗口数为0，也可以发送紧急数据；在紧急数据处理完毕之后，进程就将恢复到正常操作。

 PSH：推送位（急迫位）。目的为在报文到达对端时，将这个报文以及缓存区之间缓存尚未交付的数据一并交给进程（一般来说TCP要等整个缓存区都满了之后才会向进程交付数据）。

 区别： URG交给进程的数据只有紧急数据，而PSH交给进程的数据为缓存区里面排好序的数据以及当前报文中的数据。 URG对进程的数据的交付是不经过缓存区的，PSH对进程的数据的交付是经过缓存区的。 

三、tcp定时器 

常用的定时器： 

TCP使用四种定时器（Timer，也称为“计时器”）：

重传计时器：Retransmission Timer 

坚持计时器：Persistent Timer 

保活计时器：Keeplive Timer 

时间等待计时器：Time_Wait Timer。 

（1）重传计时器： 

        重传定时器：为了控制丢失的报文段或丢弃的报文段，也就是对报文段确认的等待时间。当TCP发送报文段时，就创建这个特定报文段的重传计时器，可能发生两种情况：若在计时器超时之前收到对报文段的确认，则撤销计时器；若在收到对特定报文段的确认之前计时器超时，则重传该报文，并把计时器复位。 Karn算法：对重传报文，在计算新的RTT时，不考虑重传报文的RTT。因为无法推理出：发送端所收到的确认是对上一次报文段的确认还是对重传报文段的确认。干脆不计入。

（2）坚持计时器：persistent timer 

        专门为对付零窗口通知而设立的。 ACK的传输并不可靠，也就是说TCP对ACK的报文段不进行确认，TCP只确认那些包含数据的报文段。为了防止因为ACK报文段丢失而双方进行等待的问题，发送方用一个坚持定时器来周期性地向接收方查询。这些从发送方发送出的报文段称为窗口探查。当发送端收到零窗口的确认时，就启动坚持计时器，当坚持计时器截止期到时，发送端TCP就发送一个特殊的报文段，叫探测报文段，这个报文段只有一个字节的数据。探测报文段有序号，但序号永远不需要确认，甚至在计算对其他部分数据的确认时这个序号也被忽略。探测报文段提醒接收端TCP，确认已丢失，必须重传。坚持计时器的截止期设置为重传时间的值，但若没有收到从接收端来的响应，则发送另一个探测报文段，并将坚持计时器的值加倍和并复位，发送端继续发送探测报文段，将坚持计时器的值加倍和复位，知道这个值增大到阈值为止（通常为60秒）。之后，发送端每隔60s就发送一个报文段，直到窗口重新打开为止；

（3）保活计时器：keeplive timer 

        每当服务器收到客户的信息，就将keeplive timer复位，超时通常设置2小时，若服务器超过2小时还没有收到来自客户的信息，就发送探测报文段，若发送了10个探测报文段（每75秒发送一个）还没收到响应，则终止连接。若 客户服务机崩溃再重启，这时服务器将收到一个对其保活探查的响应但是这个响应是一个复位，使得服务器终止这个连接。

（4）时间等待计时器：Time_Wait Timer 

        在连接终止期使用，当TCP关闭连接时，并不认为这个连接就真正关闭了，在时间等待期间，连接还处于一种中间过度状态。这样就可以时重复的fin报文段在到达终点后被丢弃，这个计时器的值通常设置为一格报文段寿命期望值的两倍。 

四、TCP的三次握手和四次挥手 

（1）三次握手 ：

什么是三次握手： 

1、A端向B端发送一个连接请求，发送报文段1。

 2、B端接收到A端发送的报文段1，如果确认请求连接信号，返回确认报文段2，即为应答报文段。 

3、A收到B的确认报文段2，反送报文段3给B，确认已经收到确认认可连接请求。 

为什么要三次握手：

        确保数据的传输准确，假设只有两次握手，在A向B发送连接请求的时候，如果B接受到请求且B允许连接请求，这样B的两次握手就已经完成的，这时候B就会开始向A传送信息，而不去管A是否已经确认或者已经打开端口。而如果B没有确认连接或者A没有收到B的确认连接，那么A就会不停地给B发送请求信息，这时候就会产生一个恶意进程，那就是A，它在不停地占用系统的资源。至于三次以上的握手，因为三次握手就已经能够准确地传达所需要的信息了，所以没必要再进行多次的确认，这样也会造成系统资源的浪费。 

（2）四次挥手 ：什么是四次挥手： 由于TCP是全双工的，因此每个方向都必须单独进行关闭。

 1、TCP客户端发送一个信号，用来关闭客户到服务的数据传输（报文段4）。

 2、服务器收到这个信号，返回一个返回一个确认报文段（5）。

 3、服务器关闭客户端的连接，同时返回一个已关闭信号报文段（6）。

 4、客户端收到连接关闭报文段，返回确认收到报文段（7）。

为什么要进行四次挥手： 

        由于TCP是全双工的，可以进行两端的数据传送，亦可以同时发送信息，所以当你一端要关闭连接的时候，如果另一端还有没有接受完的信息，或者还在传送后续分段的信息，没有四次挥手相互确认的话就会造成数据的丢失。只有当双方都确认已经完成数据的传输或者接收之后，相互确认已经可以中断连接时，才可以安全结束连接。 

（3）主动断开连接的一方为什么要进入TIME_WAIT状态 TIME_WAIT状态也称为2MSL等待状态。每个TCP必须选择一个报文段最大生存时间（MSL）。它是任何报文段被丢弃前在网络的最长时间。处理原则：当TCP执行一个主动关闭，并发送回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2MSL。这样可以让TCP再次发送最后的ACK以避免这个ACK丢失（另一端超时并重发最后的FIN）。这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口不能被使用。