TCP知识片段

欢迎您访问我爱IT技术网，今天小编为你分享的电脑教程是网络协议方面的经验知识教程：TCP知识片段，下面是详细的分享！

TCP知识片段

TCP发送情景

TCP之ACK发送情景

我现在的理解，在有以下几种情景，TCP会把ack包发出去：

1.收到1个包，启动200ms定时器，等到200ms的定时器到点了（第二个包没来），于是对这个包的确认ack被发送。这叫做“延迟发送”。

2.收到1个包，启动200ms定时器，200ms定时器还没到，第二个数据包又来了（两个数据包一个ack）。

3.收到1个包，启动200ms定时器，还没超时，正好要给对方发点内容。于是对这个包的确认ack就跟着捎过去。这叫做“捎带发送”。

4.每当TCP接收到一个超出期望序号的失序数据时，它总是发送一个确认序号为其期望序号的ACK。

5.窗口更新或者也叫做打开窗口（接收端窗口达到最大的时候，接收缓存中的数据全部推向进程导致接收缓存为空），通知发送端可以继续发送。

6.正常情况下对对方保活探针的响应

TCP之RST发送场景

1.connect一个不存在的端口；

2.向一个已经关掉的连接send数据；

3.向一个已经崩溃的对端发送数据（连接之前已经被建立）；

4.close(sockfd)时，直接丢弃接收缓冲区未读取的数据，并给对方发一个RST。这个是由SO_LINGER选项来控制的；

5.a重启，收到b的保活探针，a发rst，通知b。

TCP socket在任何状态下，只要收到RST包，即可进入CLOSED初始状态。

值得注意的是RST报文段不会导致另一端产生任何响应，另一端根本不进行确认。收到RST的一方将终止该连接。程序行为如下：

阻塞模型下，内核无法主动通知应用层出错，只有应用层主动调用read()或者write()这样的IO系统调用时，内核才会利用出错来通知应用层对端RST。

非阻塞模型下，select或者epoll会返回sockfd可读,应用层对其进行读取时，read()会报错RST。

TCP之异常关闭的意义

终止一个连接的正常方式是发送FIN。在发送缓冲区中所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失。

但我们有时也有可能发送一个RST报文段而不是FIN来中途关闭一个连接。这称为异常关闭。

进程关闭socket的默认方式是正常关闭，如果需要异常关闭，利用SO_LINGER选项来控制。

异常关闭一个连接对应用程序来说有两个优点：

（1）丢弃任何待发的已经无意义的数据，并立即发送RST报文段；

（2）RST的接收方利用关闭方式来区分另一端执行的是异常关闭还是正常关闭。

值得注意的是RST报文段不会导致另一端产生任何响应，另一端根本不进行确认。收到RST的一方将终止该连接。程序行为如下：

阻塞模型下，内核无法主动通知应用层出错，只有应用层主动调用read()或者write()这样的IO系统调用时，内核才会利用出错来通知应用层对端RST。

非阻塞模型下，select或者epoll会返回sockfd可读,应用层对其进行读取时，read()会报错RST。

haproxy的实现中用到了这个选项。

TCP选项之TCP_KEEPALIVE

KEEPALIVE机制，是TCP协议规定的TCP层（非应用层业务代码实现的）检测TCP本端到对方主机的TCP连接的连通性的行为。避免服务器在客户端出现各种不良状况时无法感知，而永远等在这条TCP连接上。

该选项可以设置这个检测行为的细节，如下代码所示：

int keepAlive=1; // 非0值，开启keepalive属性

int keepIdle=60; // 如该连接在60秒内没有任何数据往来,则进行此TCP层的探测

int keepInterval=5; // 探测发包间隔为5秒

int keepCount=3; // 尝试探测的次数.如果第1次探测包就收到响应了,则后2次的不再发

setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));

setsockopt(sockfd, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));

setsockopt(sockfd, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));

setsockopt(sockfd, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount));

设置该选项后，如果60秒内在此套接口所对应连接的任一方向都没有数据交换，TCP层就自动给对方发一个保活探测分节(keepalive probe)。这是一个对方必须响应的TCP分节。它会导致以下三种情况：

对方接收一切正常：以期望的ACK响应。60秒后，TCP将重新开始下一轮探测。

对方已崩溃且已重新启动：以RST响应。套接口的待处理错误被置为ECONNRESET。

对方无任何响应：比如客户端那边已经断网，或者客户端直接死机。以设定的时间间隔尝试3次，无响应就放弃。套接口的待处理错误被置为ETIMEOUT。

全局设置可更改/etc/sysctl.conf,加上:

net.ipv4.tcp_keepalive_intvl=5

net.ipv4.tcp_keepalive_probes=3

net.ipv4.tcp_keepalive_time=60

在程序中表现为：

阻塞模型下，当TCP层检测到对端socket不再可用时，内核无法主动通知应用层出错，只有应用层主动调用read()或者write()这样的IO系统调用时，内核才会利用出错来通知应用层。

非阻塞模型下，select或者epoll会返回sockfd可读,应用层对其进行读取时，read()会报错。

一点经验：

实际上我们在做服务器程序的时候，对客户端的保活探测基本上不依赖于这个TCP层的keepalive探测机制。

而是我们自己做一套应用层的请求应答消息，在应用层实现这样一个功能。

TCP选项之SO_RCVBUF和SO_SNDBUF

SO_RCVBUF SO_SNDBUF

先明确一个概念：每个TCP socket在内核中都有一个发送缓冲区和一个接收缓冲区，TCP的全双工的工作模式以及TCP的滑动窗口便是依赖于这两个独立的buffer以及此buffer的填充状态。接收缓冲区把数据缓存入内核，应用进程一直没有调用read进行读取的话，此数据会一直缓存在相应socket的接收缓冲区内。再啰嗦一点，不管进程是否读取socket，对端发来的数据都会经由内核接收并且缓存到socket的内核接收缓冲区之中。read所做的工作，就是把内核缓冲区中的数据拷贝到应用层用户的buffer里面，仅此而已。进程调用send发送的数据的时候，最简单情况（也是一般情况），将数据拷贝进入socket的内核发送缓冲区之中，然后send便会在上层返回。换句话说，send返回之时，数据不一定会发送到对端去（和write写文件有点类似），send仅仅是把应用层buffer的数据拷贝进socket的内核发送buffer中。后续我会专门用一篇文章介绍read和send所关联的内核动作。每个UDP socket都有一个接收缓冲区，没有发送缓冲区，从概念上来说就是只要有数据就发，不管对方是否可以正确接收，所以不缓冲，不需要发送缓冲区。

接收缓冲区被TCP和UDP用来缓存网络上来的数据，一直保存到应用进程读走为止。对于TCP，如果应用进程一直没有读取，buffer满了之后，发生的动作是：通知对端TCP协议中的窗口关闭。这个便是滑动窗口的实现。保证TCP套接口接收缓冲区不会溢出，从而保证了TCP是可靠传输。因为对方不允许发出超过所通告窗口大小的数据。 这就是TCP的流量控制，如果对方无视窗口大小而发出了超过窗口大小的数据，则接收方TCP将丢弃它。 UDP：当套接口接收缓冲区满时，新来的数据报无法进入接收缓冲区，此数据报就被丢弃。UDP是没有流量控制的；快的发送者可以很容易地就淹没慢的接收者，导致接收方的UDP丢弃数据报。

以上便是TCP可靠，UDP不可靠的实现。

这两个选项就是来设置TCP连接的两个buffer尺寸的。

深入浅出TCP之半关闭与CLOSE_WAIT

终止一个连接要经过4次握手。这由TCP的半关闭（half-close）造成的。既然一个TCP连接是全双工（即数据在两个方向上能同时传递，可理解为两个方向相反的独立通道），因此每个方向必须单独地进行关闭。这原则就是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向连接。当一端收到一个FIN，内核让read返回0来通知应用层另一端已经终止了向本端的数据传送。发送FIN通常是应用层对socket进行关闭的结果。

例如：TCP客户端发送一个FIN，用来关闭从客户到服务器的数据传送。

半关闭对服务器究竟有什么影响呢？先看看下面的TCP状态转化图

tcp状态装换图

客户端主动关闭时，发出FIN包，收到服务器的ACK，客户端停留在FIN_WAIT2状态。而服务端收到FIN，发出ACK后，停留在COLSE_WAIT状态。

这个CLOSE_WAIT状态非常讨厌，它持续的时间非常长，服务器端如果积攒大量的COLSE_WAIT状态的socket，有可能将服务器资源耗尽，进而无法提供服务。

那么，服务器上是怎么产生大量的失去控制的COLSE_WAIT状态的socket呢？我们来追踪一下。

一个很浅显的原因是，服务器没有继续发FIN包给客户端。

服务器为什么不发FIN，可能是业务实现上的需要，现在不是发送FIN的时机，因为服务器还有数据要发往客户端，发送完了自然就要通过系统调用发FIN了，这个场景并不是上面我们提到的持续的COLSE_WAIT状态，这个在受控范围之内。

那么究竟是什么原因呢，咱们引入两个系统调用close(sockfd)和shutdown(sockfd,how)接着往下分析。

在这儿，需要明确的一个概念---- 一个进程打开一个socket，然后此进程再派生子进程的时候，此socket的sockfd会被继承。socket是系统级的对象，现在的结果是，此socket被两个进程打开，此socket的引用计数会变成2。

继续说上述两个系统调用对socket的关闭情况。

调用close(sockfd)时，内核检查此fd对应的socket上的引用计数。如果引用计数大于1，那么将这个引用计数减1，然后返回。如果引用计数等于1，那么内核会真正通过发FIN来关闭TCP连接。

调用shutdown(sockfd，SHUT_RDWR)时,内核不会检查此fd对应的socket上的引用计数，直接通过发FIN来关闭TCP连接。

现在应该真相大白了，可能是服务器的实现有点问题，父进程打开了socket，然后用派生子进程来处理业务，父进程继续对网络请求进行监听，永远不会终止。客户端发FIN过来的时候，处理业务的子进程的read返回0，子进程发现对端已经关闭了，直接调用close()对本端进行关闭。实际上，仅仅使socket的引用计数减1，socket并没关闭。从而导致系统中又多了一个CLOSE_WAIT的socket。。。

如何避免这样的情况发生？

子进程的关闭处理应该是这样的：

shutdown(sockfd, SHUT_RDWR);

close(sockfd);

这样处理，服务器的FIN会被发出，socket进入LAST_ACK状态，等待最后的ACK到来，就能进入初始状态CLOSED。

补充一下shutdown()的函数说明

linux系统下使用shutdown系统调用来控制socket的关闭方式

int shutdown(int sockfd,int how);

参数 how允许为shutdown操作选择以下几种方式：

SHUT_RD：关闭连接的读端。也就是该套接字不再接受数据，任何当前在套接字接受缓冲区的数据将被丢弃。进程将不能对该套接字发出任何读操作。对TCP套接字该调用之后接受到的任何数据将被确认然后被丢弃。

SHUT_WR:关闭连接的写端。

SHUT_RDWR:相当于调用shutdown两次：首先是以SHUT_RD,然后以SHUT_WR

注意:

在多进程中如果一个进程中shutdown(sfd, SHUT_RDWR)后其它的进程将无法进行通信. 如果一个进程close(sfd)将不会影响到其它进程.

以上就是关于TCP知识片段的网络协议知识分享，更多电脑教程请移步到>>电脑教程。