客户端向服务器端发送连接请求后,就被动地等待服务器的响应。典型的TCP客户端要经过下面三步操作:
1. 创建一个Socket实例:构造函数向指定的远程主机和端口建立一个TCP连接;
2. 通过套接字的I/O流与服务端通信;
3. 使用Socket类的close方法关闭连接。
服务端的工作是建立一个通信终端,并被动地等待客户端的连接。典型的TCP服务端执行如下操作:
1. 创建ServerSocket对象,绑定并监听端口
2. 通过accept监听客户端的请求
3. 建立连接后,通过输出输入流进行读写操作
4. 关闭相关资源
世界上绝大部分的 HTTP 通信都是通过 TCP/IP 承载的,TCP/IP 是全球计算机和网络设备都在使用的一种常用的分组交换网络分层协议集。客户端应用程序可以打开一条 TCP/IP 连接,连接到世界上可能运行的任何一个服务器应用程序上。一旦连接建立起来,在不断网的情况下,客户端与服务器之间交换的报文就永远不会丢失、受损或者失序。1、先提出一个问题, 可以不进行三次握手直接往服务端发送数据包吗?
是不可以的,也是可以的 ;
1)不可以是因为现在的TCP连接标准和规范要求传输数据前先确认两端的状态,有一端状态不OK的话,发数据包有什么用呢;
2)说可以是站在网络连接的角度,像 UDP 协议;
2、TCP三次握手
1)标志位、随机序列号和确认序列号是在数据包的 TCP 首部里面;
2)几个状态是指客户端和服务端连接过程中 socket 状态;
3)第一次握手,客户端向服务端发送数据包,该数据包中 SYN 标志位为 1,还有随机生成的序列号c_seq,客户端状态改为 SYN-SENT ;
4)第二次握手,服务端接收到客户端发过来的数据包中 SYN 标志位为 1,就知道客户端想和自己建立连接,服务端会根据自身的情况决定是拒绝连接,或确定连接,还是丢弃该数据包;
拒绝连接,会往客户端发一个数据包,该数据包中 RST 标志位为 1,客户端会报 Connection refused ;
丢弃客户端的数据包,超过一定时间后客户端会报 Connection timeout;
确定连接时会往客户端发一个数据包,该数据包中 ACK 标志位为 1,确认序列号 ack=c_seq+1,SYN 标志位为 1,随机序列号 s_seq,状态由 LISTEN 改为 SYN-RCVD ;
5)第三次握手,客户端接收到数据包会做校验,校验ACK标志位和确认序列号 ack=c_seq+1,如果确定是服务端的确认数据包,改自己的状态为 ESTABLISHED ,并给服务端发确认数据包;
6)服务端接到客户端数据包,会校验ACK标志位和确认序列号 ack=s_seq+1,改自己的状态为 ESTABLISHED ,之后就可以进行数据传输了;
7)建立连接时的数据包是没有实际内容的,没有应用层的数据;
8)建立连接之后发起的请求数据包,每个数据包都会封装各层协议的头部信息,标志位ACK为1,其他标志位变动;
9)网络进程间的通信,一台服务器内部的进程间通信不用这样;
3、TCP 连接三次握手抓包
1)Socket 在 linux 系统中是一种特殊的文件,因为 linux 系统的理念就是【一切皆文件】,是系统内核级的功能;
2)以上定义比较具体,可以抽象来理解,是一个内核级的用于通信的功能层,包含一组接口函数,这些函数实际就是操作 socket 文件句柄文件描述符;
一个 TCP 连接由四要素【源IP、源Port、目标IP、目标Port】唯一标识,也即 socket 由这四要素唯一确定;
一个 TCP 连接的建立也就是客户端、服务端创建了相对应的一对 socket,客户端和服务端之间的通信也就是这对 socket 间的通信(物理层面是网卡在发送/接收比特流数据);
3) 一个服务与另一个服务建立连接,他们的端口是什么呢 ?
客户端发出请求端口号是随机的,服务端是进程监听的端口号;
2、socket 主要函数介绍
1、进程通信,一个进程只有一个监听 socket,connect socket 是针对一个客户的一个连接的,有很多个; 2、connect 函数内部在发起请求前会找系统随机一个端口号; 3、连接建立后,客户端发起请求传输数据,服务端会直接交给 connect socket 处理,不会交给监听 socket 处理;
4、监听 socket 在处理客户端请求时,如果此时其他客户端发请求过来,监听 socket 是没法处理的,此时系统会维护请求队列由 backlog 参数指定;
全连接队列(completed connection queue)
半连接队列(incomplete connection queue)
Linux 内核 2.2 版本之前 ,backlog 的大小等于全连接队列和半连接队列之和;
Linux 内核 2.2 版本之后 ,backlog 的大小之和全连接队列有关系:
半连接队列大小由 /proc/sys/net/ipv4/tcp_max_syn_backlog 文件指定,可以开很大;
全连接队列大小由 /proc/sys/net/core/somaxconn 文件和 backlog 参数指定,取两个中的最小值;
tomcat acceptCount 就是配置全连接队列大小;
3、socket 函数在建立连接和数据传输的大概使用情况
4、TCP首部结构
1)2的16次方等于 65536,所以系统中端口号的限制个数为 65536,一般1024以下端口被系统占用;
2)标志位这里是 6 个,还有其他标志位的,只是这 6 个标志位常用;
3)seq 序列号,ack 确认序列号,序列号在数据传输时分包用到。三次握手时 seq 序列号是随机的,没有实际意义;
4)TCP 包首部后面接着的是 IP 包首部,再紧接着的是以太网包首部,其实都是加 0101010101 二进制位;
几个常用标志位,首先一个标志位占一个 bit 位,只能是二进制中的 1 或 0;
1)SYN ,简写 S ,请求标志位,用来建立连接。在TCP三次握手中收到带有该标志位的数据包,表示对方想与己方建立连接;
2)ACK ,简写【.】 ,请求确认/应答标志位,用于对对方的请求进行应答,对方收到含该标志位的数据包,会知道己方存在且可用。也会用在连接建立之后,己方发送响应数据给对方的数据包中;
3)FIN ,简写 F ,请求断开标志位,用于断开连接。对方收到己方的含该标志位的数据包,就知道己方想与它断开连接,不再保持连接;
4)RST ,简写 R ,请求复位标志位,因网络或己方服务原因导致有数据包丢失,己方接收到的数据包序列号与上一个数据包的序列号不衔接,那己方会发送含该标志位的数据包告诉对方,对方接收到含该标志位的数据包就知道己方要求它重新三次握手建立连接并重新发送丢失的数据包,一般断点续传会用到该标志位;
还有就是如果对方发过来的数据错了,有问题,己方也会发送含该标志位的数据包;
5)PSH ,简写 P ,推送标志位,表示收到数据包后要立即交给应用程序去处理,不应该放在缓存中,read()/write() 都有缓存区;
6)URG ,简写 U ,紧急标志位,该标志位表示 tcp 包首部中的紧急指针域有效,督促中间层尽快处理;
7)ECE,在保留位中;
8)CWR,在保留位中;
5、TCP 抓包
1)服务端会根据自身情况,没有要处理的数据时会把第二次和第三次挥手合并成一次挥手,此时标志位 FIN=1 / ACK=1;
2)MSL 是 Maximum Segment Lifetime 缩写,指数据包在网络中最大生存时间,RFC 建议是 2分钟;
详细描述:
1)客户端、服务端都可以主动发起断开连接;
2)第一次挥手,客户端向服务端发送含 FIN=1 标志位的数据包,随机序列号 seq=m,此时客户端状态由 ESTABLISHED 变为 FIN_WAIT_1 ;
3)第二次挥手,服务端收到含 FIN=1 标志位的数据包,就知道客户端要断开连接,服务端会向客户端发送含 ACK=1 标志位的应答数据包,确认序列号 ack=m+1,此时服务端状态由 ESTABLISHED 变为 CLOSE_WAIT ;
4)客户端收到含 ACK=1 标志位的应答数据包,知道服务端的可以断开的意思,此时客户端状态由 FIN_WAIT_1 变为 FIN_WAIT_2 ;(第一、二次挥手也只是双方交换一下意见而已)
5)第三次挥手,服务端处理完剩下的数据后再次向客户端发送含 FIN=1 标志位的数据包,随机序列号 seq=n,告诉客户端现在可以真正的断开连接了,此时服务端状态由 CLOSE_WAIT 变为 LAST_ACK ;
6)第四次挥手,客户端收到服务端再次发送的含 FIN=1 标志位的数据包,就知道服务端处理好了可以断开连接了,但是客户端为了慎重起见,不会立马关闭连接,而是改状态,且向服务端发送含 ACK=1 标志位的应答数据包,确认序列号 ack=n+1,此时客户端状态由 FIN_WAIT_2 变为 TIME_WAIT ;
等待 2 个MSL 时间还是未收到服务端发过来的数据,则表明服务端已经关闭连接了,客户端也会关闭连接释放资源,此时客户端状态由 TIME_WAIT 变为 CLOSED ;
也就是说 TIME_WAIT 状态存在时长在 1~4分钟;
7)服务端收到含 ACK=1 标志位的应答数据包,知道客户端确认可以断开了,就立即关闭连接释放资源,此时服务端状态由 LAST_ACK 变为 CLOSED ;
SYN 洪水攻击(SYN Flood)
是一种 DoS攻击(拒绝服务攻击),大概原理是伪造大量的TCP请求,服务端收到大量的第一次握手的数据包,且都会发第二次握手数据包去回应,但是因为 IP 是伪造的,一直都不会有第三次握手数据包,导致服务端存在大量的半连接,即 SYN_RCVD 状态的连接,导致半连接队列被塞满,且服务端默认会发 5 个第二次握手数据包,耗费大量 CPU 和内存资源,使得正常的连接请求进不来;
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)