TCP

Tcp wrappers : Transmission Control Protocol (TCP) Wrappers 为由 inetd 生成的服务提供了增强的安全性。TCP Wrappers 是一种对使用 /etc/inetd.sec 的替换方法。TCP Wrappers 提供防止主机名和主机地址欺骗的保护。欺骗是一种伪装成有效用户或主机以获得对系统进行未经授权的访问的方法。

在因特网协议族（Internet protocol suite）中，TCP层是位于IP层之上，应用层之下的传输层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，然后TCP把数据流分割成适当长度的报文段（通常受该计算机连接的网络的数据链路层的最大传送单元（MTU）的限制）。之后TCP把结果包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。TCP为了保证不发生丢包，就给每个字节一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认（ACK）；如果发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据（假设丢失了）将会被重传。TCP用一个校验和函数来检验数据是否有错误；在发送和接收时都要计算和校验。首先，TCP建立连接之后，通信双方都同时可以进行数据的传输，其次，它是全双工的；在保证可靠性上，采用超时重传和捎带确认机制。在流量控制上，采用滑动窗口协议，协议中规定，对于窗口内未经确认的分组需要重传。在拥塞控制上，采用广受好评的TCP拥塞控制算法（也称AIMD算法），该算法主要包括三个主要部分：1，加性增、乘性减；2，慢启动；3，对超时事件做出反应。

简单来说 TCP就是传输协议 应用于计算机网络的传输层

我们在之前的学习中了解到 计算机网络编程时如果传输层使用的传输协议是TCP 那么客户端和服务器之间就需要同构三次握手建立连接以及通过四次挥手终止连接状态

那么在这个三次握手和四次挥手期间就涉及到了TCP状态的转移

TCP状态转移

图3-8就是TCP中客户端和服务器建立连接和关闭连接时的TCP状态

我们打开以往编写的服务器和客户端并建立连接 然后查看他们的状态

 

我们可以看到这里有一种TIME_WAIT状态

在TCP各个状态中 我们发现客户端和服务器都是收到了对方的某个报文才进行响应的响应

那么在结束时 就像我们和别人打电话一样 那么我们在讲完事情之后说“我讲完了，我挂断了”

那么我们都要要听到对面回复说那你挂断吧 我们才挂断 我们在等待对方说挂断的这个时间段就是在TCP状态中意味着的TIME_WAIT状态

TIME_WAIT状态

  从图3-9来看，客户端连接在收到服务器的结束报文段（TCP报文段6)之后，并没有直接进人CLOSED状态9，而是转移到TIME_WAIT状态。在这个状态，客户端连接要等待一段长为2MSL (Maximum Segment Life，报文段最大生存时间）的时间，才能完全关闭。MSL是TCP报文段在网络中的最大生存时间，标准文档RFC1122的建议值是2 min。

那么我们存在TIME_WAIT状态的意义是什么呢

 第一个原因很好理解。假设图3-9中用于确认服务器结束报文段6的TCP报文段7丢失，那么服务器将重发结束报文段。因此客户端需要停留在某个状态以处理重复收到的结束报文段（即向服务器发送确认报文段)。否则，客户端将以复位报文段来回应服务器，服务器则认为这是一个错误，因为它期望的是一个像TCP报文段7那样的确认报文段。
在Linux系统上，一个TCP端口不能被同时打开多次（两次及以上)。当一-个TCP连接处于TIME_WAIT状态时，我们将无法立即使用该连接占用着的端口来建立一个新连接。反过来思考，如果不存在TIME_WAIT状态，则应用程序能够立即建立一个和刚关闭的连接相似的连接（这里说的相似，是指它们具有相同的IP地址和端口号)。这个新的、和原来相似的连接被称为原来的连接的化身(incarnation)。新的化身可能接收到属于原来的连接的、携带应用程序数据的TCP报文段〈迟到的报文段)，这显然是不应该发生的。这就是TIMEWAIT状态存在的第二个原因。
另外，因为TCP报文段的最大生存时间是MSL，所以坚持2MSL时间的TIME_WAIT状态能够确保网络上两个传输方向上尚未被接收到的、迟到的TCP报文段都已经消失（被中转路由器丢弃)。因此，一个连接的新的化身可以在2MSL时间之后安全地建立，而绝对不会接收到属于原来连接的应用程序数据，这就是TIME_WAIT状态要持续2MSL时间的原因。
有时候我们希望避免TIME_WAIT状态，因为当程序退出后，我们希望能够立即重启它。但由于处在TIME_WAIT状态的连接还占用着端口，程序将无法启动(直到2MSL超时时间结束)。考虑一个例子:在测试机器ernest-laptop上以客户端方式运行nc（用于创建网络连接的.工具，见第17章）命令，登录本机的Web服务，且明确指定客户端使用12345端口与服务器通信。然后从终端输人Ctrl+C终止客户端程序，接着又立即重启nc程序，以完全相同的方式再次连接本机的Web 服务。这里我们使用netstat命令查看连接的状态。其输出显示，客户端程序被中断后，连接进入TIME_WAIT状态，12345端口仍被占用，所以客户端重启失败。
对客户端程序来说，我们通常不用担心上面描述的重启问题。因为客户端一般使用系统自动分配的临时端口号来建立连接，而由于随机性，临时端口号一般和程序上一次使用的端口号(还处于TIME_WAIT状态的那个连接使用的端口号）不同，所以客户端程序一般可以立即重启。上面的例子仅仅是为了说明问题，我们强制客户端使用12345端口，这才导致立即重启客户端程序失败。
但如果是服务器主动关闭连接后异常终止，则因为它总是使用同一个知名服务端口号，所以连接的TIME_WAIT状态将导致它不能立即重启。不过，我们可以通过socket选项SO_REUSEADDR来强制进程立即使用处于TIME_WAIT状态的连接占用的端口，这将在第5章讨论。