TCP/IP众所周知在连接的时候,需要经历三次握手,而在终止的时候需要经历四次(有某些是以三次实现)握手才能“完美的”终止一次TCP/IP,因为TCP/IP的可靠性导致了一种互不信任的通信模式。故非此周折;
TCP/IP三次握手过程。
三次握手好理解。下面是TCP/IP关闭的四次握手流程图;
当一方发送close的时候,则向服务器发送一个FIN报文分节。得到服务器的响应,这个时候,客户机无法再进行任何的读写,也许会存在位于客户机套接字发送缓存区的数据没有发送的问题。这个时候,可以选择设置SO_LINGER选项。将close进行限时阻塞。这个时候服务器如果进行读写的话,则读会读取到流结束符,写会导致异常抛出。
C++服务器代码:
服务器主要是读从客户端中读取字节。
C++客户端:
客户端主要是持续的向服务器写入字节;
另外用JAVA代码进行了一个C/S程序做对比;
JAVA服务器:
JAVA客户端代码:
在LINUX系统中,每一个合理关闭(main执行结束)和意外关闭(SIGKILL)被系统中断的程序,都在结束的时候向远程服务器发送一个FIN分节。
其中四个程序分别运行在以下环境:
C++ server:Fedora
C++ client:cygwin windows
JAVA server:windows
JAVA client:windows
下面分别是几种关闭客户端进程的情况:
JAVA客户端退出
1) 非正常终止(不显示调用close):
a) 服务器读:Connection reset异常;
b) 服务器写:socket write error;
2) close终止:
a) 服务器读:-1,流结束符;
b) 服务器写:socket write error;
C++客户端退出
1) 非正常终止(不显示调用close):
a) 服务器读:0,流结束符
b) 服务器写:-1 异常
2) close终止:
a) 服务器读:0,流结束符;
b) 服务器写:-1 异常
TCP/IP的状态图如下:
状态描述:
1) 服务器启动。这个时候状态为
状态为:
2) 客户端连接:
客户机状态和服务器状态:
这个时候,我们可以用tcpdump看到两台机器中不断的发送数据,
3)关闭客户端
此时服务器状态为
这个时候,我们在tcpdump中可以见到:
在服务器ACK之前,事实上客户端经历了FIN_WAIT_1的状态,不过因为服务器很快的给予了FIN的ACK答复分节,所以这个过程转瞬即逝。
此时,客户端和服务器之间实现了所谓的半关闭。
3) 关闭服务器
客户机状态为:
我们tcpdump查看的数据为:
这表示服务器那半连接也被关闭了。
我们也可以采用JAVA客户端在WINDOWS平台上连接Fedora的C++服务器,我们在tcpdump中发现如果我们不执行close操作,则不会向服务器发送FIN分节,这也是导致了为什么在讨论JAVA客户端非正常关闭的情况下,read的结果是系统异常而不是流结束符。
TIME_WAIT一般会经历两个MSL,主要是为了防止化身进程和上一个关闭的进程在网络中还没有接受到的分节产生混淆。