Socket是什么呢?
Socket是应用层与TCP/IP协议族通信的中间软件抽象层,它是一组接口。在设计模式中,Socket其实就是一个门面模式,它把复杂的TCP/IP协议族隐藏在Socket接口后面,对用户来说,一组简单的接口就是全部,让Socket去组织数据,以符合指定的协议。不过Socket在不同的语境中有不同的含义,如再说TCP连接的俩个端点时,Socket的含义是套接字,Socket=ip:port。我们本次主要讨论的是,Socket作为一组接口的含义。
应用层使用Socket接口进行进程间的通信,一般我们会将主动接收消息的一端称为服务器端,主动发送消息的一端称为客户端。先从服务器端说起。服务器端先初始化Socket,然后与端口绑定(bind),对端口进行监听(listen),调用accept阻塞,等待客户端连接。在这时如果有个客户端初始化一个Socket,然后连接服务器(connect),如果连接成功,这时客户端与服务器端的连接就建立了。客户端发送数据请求,服务器端接收请求并处理请求,然后把回应数据发送给客户端,客户端读取数据,最后关闭连接,一次交互结束。
Socket 客户端与服务器段进行连接与释放链接要经过三次握手和四次挥手,以下基于TCP三次握手建立连接、四次挥手断开连接进行详解。
TCP报文首部内容:
位码即tcp标志位,有6种标示:
SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急) Sequence number(顺序号码) Acknowledge number(确认号码)
名词详解:
序列号seq:占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;给字节编上序号后,就给每一个报文段指派一个序号;序列号seq就是这个报文段中的第一个字节的数据编号。
确认号ack:占4个字节,期待收到对方下一个报文段的第一个数据字节的序号;序列号表示报文段携带数据的第一个字节的编号;而确认号指的是期望接收到下一个字节的编号;因此当前报文段最后一个字节的编号+1即为确认号。
确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效
同步SYN:连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建立连接时才会被置1,握手完成后SYN标志位被置0。
终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接
PS:ACK、SYN和FIN这些大写的单词表示标志位,其值要么是1,要么是0;ack、seq小写的单词表示序号。
TCP三次握手
所谓三次握手(Three-way Handshake),是指建立一个TCP连接时,需要客户端和服务器总共发送3个包即交互三次。 三次握手的目的是确认交互双方的活动状态。在socket编程中,客户端执行connect()时。将触发三次握手。
1、 第一次,有客户端调用connect 触发。客户端发送一个报文,其中SYN=1,代表本次请求建立连接,同时发送了一个序列号seq = x。
2、 第二次,服务器端接收到客户端的请求,返回一个确认包。确认包包含 (SYN=1,AKC=1),表示服务端请求与客户端连接。ack(确认号码)的值为客户端请求的序列号+1。同时也发送一个序列号给客户端。此时客户端收到通知后,已经知道了服务器端可以正常接收和发送消息。但是服务器端并不知道客户端是否可以正常接收消息。所有就需要第三次握手。
3、 第三次,客户端向服务器端返回一个确认包(ACK=1),其中确认号码ack为服务器端发送的序列号码+1和一个序列号Z。服务器接收到后可以确认客户端有接收能力。此时,双方已经确认对方都具有发送和接收的能力,客户端和服务器已经完成了双向连接的建立。
客户端的connect在三次握手的第二个次返回,而服务器端的accept在三次握手的第三次返回。 PS:注意字母大小写不同表示的含义不同
TCP 四次挥手
TCP的连接的拆除需要发送四个包即四次交互,因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作,在Socket编程中,任何一方执行close()操作即可产生挥手操作。
由于TCP连接是全双工通信的,因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。
客户端主动关闭连接,之后服务器端关闭连接: 1、 客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
2、 服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
3、 客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
4、 服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
5、 客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。 5.1 、 客户端为什么要等待2_MSL 客户端返回最后的确认包,服务器端接收到确认包后进入关闭状态。但是确认包有可能丢失,如果服务器端长时间没有收到确认,会触发超时重传机制,所以在2_MSL的时间段内,客户端必须还具有接收能力。这也是为什么客户端请求的时候不需要指定自身的端口,因为这个端口会被占用一端时间,如果再次发起请求,就回出现端口被占用的情况,所以使用随机端口。
6、 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。
抓包样例:
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
本文并非原创内容,仅做了知识整理,便于自己理解与记忆 参考连接
https://blog.csdn.net/qq_38950316/article/details/81087809(清晰) https://www.cnblogs.com/zmlctt/p/3690998.html https://www.cnblogs.com/wangcq/p/3520400.html