URG与PSH:
1.在TCP协议的报头中，有6个控制位其中一个控制位位URG,URG为紧急指针字段。即使所发送的报文段的优先级大于其他数据。例如：已经发送了很长的一段数据要在远程主机上运行。突然要中断这个数据，则用户在键盘上输入control+c键，如果没有紧急指针字段，则会将数据放在末尾，到数据发送完才收到信号，因此紧急指针字段打乱了TCP数据段的发送顺序。
还有一点，URG所发的数据报不进入缓冲区直接交付给上层。
URG需要配合16位的紧急指针来使用。
2.PSH：PSH即PUSH，也为TCP报头中的控制位，当一个TCP数据段中将PSH置为1，则这个数据报会连着缓冲区之前缓冲区中的所有数据段即刻交付给上层，不会等到缓冲区满了，在缓存中停留。
端口
端口在报文中所占的位数为16位，因此可以得出一共有2^16个端口，即65536个端口。
端口的分类
根据端口和服务的绑定情况，端口可分为公认端口、注册端口和动态端口。
公认端口：0～1023。这个范围内的端口系统一般保留给一些常用的系统服务，比如WEB服务使用80端口，FTP服务使用21端口。因为这些端口和服务形成了一一对应关系，已被大家所公认，所以这些端口叫做公认端口。
注册端口：1024～49151。这个范围内的端口比较松散地绑定于一些服务，也就是说，和公认端口相比，这些端口和服务并没有形成一一对应关系，许多服务可绑定于这些端口，这些端口同样可用于许多其它目的
动态端口：49152～65535。这个范围内的端口一般不为服务所使用，它常常被动态分配给客户端，因而这个范围内的端口叫做动态端口。需要注意的是在实际应用中，端口从1024起就开始动态分配了。
常见端口：
443端口 端口说明：443端口即网页浏览端口，主要是用于HTTPS服务，是提供加密和通过安全端口传输的另一种HTTP。在一些对安全性要求较高的网站，比如银行、证券、购物等，都采用HTTPS服务，这样在这些网站上的交换信息其他人都无法看到，保证了交易的安全性。网页的地址以https://开始，而不是常见的http://。 端口漏洞：HTTPS服务一般是通过SSL（安全套接字层）来保证安全性的，但是SSL漏洞可能会受到黑客的攻击，比如可以黑掉在线银行系统，盗取信用卡账号等。 操作建议：建议开启该端口，用于安全性网页的访问。另外，为了防止黑客的攻击，应该及时安装微软针对SSL漏洞发布的最新安全补丁。
80端口 端口说明：80端口是为HTTP（HyperText Transport Protocol，超文本传输协议）开放的。 端口漏洞：有些木马程序可以利用80端口来攻击计算机的，比如Executor、RingZero等。 操作建议：为了能正常上网冲浪，我们必须开启80端口。
69端口 端口说明：69端口是为TFTP（Trival File Tranfer Protocol，次要文件传输协议）服务开放的。 端口漏洞：很多服务器和Bootp服务一起提供TFTP服务，主要用于从系统下载启动代码。可是，因为TFTP服务可以在系统中写入文件，而且黑客还可以利用TFTP的错误配置来从系统获取任何文件。 操作建议：建议关闭该端口。
21端口：
端口说明：21端口主要用于FTP（File Transfer Protocol，文件传输协议）服务。 操作建议：因为有的FTP服务器可以通过匿名登录，所以常常会被黑客利用。另外，21端口还会被一些木马利用，比如Blade Runner、FTP Trojan、Doly Trojan、WebEx等等。如果不架设FTP服务器，建议关闭21端口
三次握手与四次挥手
假设客户机client向服务器发起连接请求
（1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
（2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
（3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
为什么要进行三次握手？
假设两次握手，首先客户机向服务器发送连接请求，服务器收到了，并回应请求给客户机，因此建立了连接。
假设client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
也可以理解为如果要保证双方是能够通信的，最少发送的报文是三次。
四次挥手
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。
（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
（3） 服务器关闭客户端的连接，发送一个FIN给客户端。
（4） 客户端发回ACK报文确认，并将确认序号设置为收到序号加1。
为什么要四次挥手？
关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步挥手。
为什么主动发起断开连接的一方要进入TIME-WAIT状态？
虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可能最后一个ACK丢失（这里指客户机）。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
TCP中常用的定时器：
保活定时器(keepalive timer)
在TCP连接建立的时候指定了SO_KEEPALIVE，保活定时器才会生效。如果客户端和服务端长时间没有数据交互，那么需要保活定时器来判断是否对端还活着，因为如果由于机器的故障，导致连接一直建立而浪费资源。因此保活计时器，每隔两小时发送一次探测，如果没有回应，则在后面的每隔75分发一次探测，一连发了10此都没有回应，则服务端断开连接。
TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer)
TIME_WAIT是主动关闭连接的一端最后进入的状态， 而不是直接变成CLOSED的状态， 为什么呢？第一个原因是万一被动关闭的一端在超时时间内没有收到最后一个ACK， 则会重发最后的FIN，2MSL（报文段最大生存时间）等待时间保证了重发的FIN会被主动关闭的一段收到且重新发送最后一个ACK；另外一个原因是在2MSL等待时间时，任何迟到的报文段会被接收并丢弃，防止老的TCP连接的包在新的TCP连接里面出现。不可避免的，在这个2MSL等待时间内，不会建立同样(源IP, 源端口，目的IP，目的端口)的连接。
重传定时器(retransmission timer)
重传定时器在TCP发送数据时设定，在计时器超时后没有收到返回的确认ACK，发送端就会重新发送队列中需要重传的报文段。使用RTO重传计时器一般有如下规则：
当TCP发送了位于发送队列最前端的报文段后就启动这个RTO计时器；
如果队列为空则停止计时器，否则重启计时器；
当计时器超时后，TCP会重传发送队列最前端的报文段；
当一个或者多个报文段被累计确认后，这个或者这些报文段会被清除出队列
重传计时器保证了接收端能够接收到丢失的报文段，继而保证了接收端交付给接收进程的数据始终的有序完整的。因为接收端永远不会把一个失序不完整的报文段交付给接收进程。应用于超时重传。
建立连接定时器(connection-establishment timer)
顾名思义，这个定时器是在建立连接的时候使用的， 我们知道， TCP建立连接需要3次握手。
建立连接的过程中，在发送SYN时， 会启动一个定时器(默认应该是3秒)，如果SYN包丢失了， 那么3秒以后会重新发送SYN包的(当然还会启动一个新的定时器， 设置成6秒超时)，当然也不会一直没完没了的发SYN包， 在/proc/sys/net/ipv4/tcp_syn_retries 可以设置到底要重新发送几次SYN包。
坚持定时器(persist timer)
我们已经知道TCP通过让接收方指明希望从发送方接收的数据字节数（即窗口大小）来进行流量控制。如果窗口大小为 0会发生什么情况呢？这将有效地阻止发送方传送数据，直到窗口变为非0为止。接收端窗口变为非0后，就会发送一个确认ACK指明需要的报文段序号以及窗口大小。
如果这个确认ACK丢失了，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据（因为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。