TCP 消息的可靠性首先来自于有效的连接建立, 所以在数据进行传输前, 需要通过三次 握手建立一个连接,所谓的三次握手,就是在建立 TCP 链接时,需要客户端和服务端总共发 送 3 个包来确认连接的建立,在 socket 编程中,这个过程由客户端执行 connect 来触发
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)
(SYN=1, seq=x)客 户 端 发 送 一 个TCP 的 SYN 标志位置 1 的包,指明客户端打算连接的服务器的端口,以及初始序号 X,保存在 包 头 的 序 列 号 (SequenceNumber)字段里。发送完毕后,客户端 进 入SYN_SEND 状态。
(SYN=1, ACK=1,seq=y,ACKnum=x+1):服务器发回确认包(ACK) 应 答 。 即SYN 标 志 位 和ACK 标 志 位 均 为1。服务器端选择自己 ISN 序列号,放 到 Seq 域里,同时将 确 认 序 号(Acknowledgement Number)设置为客户的 ISN 加 1,即 X+1。发送完毕后,服务器 端 进 入SYN_RCVD 状态。
客户端再次发送确认包(ACK), SYN 标志位为 0, ACK 标志位为 1,并且把服务器发来 ACK 的序号字段+1,放在确定字段中发送给对方,并且在数据段放写 ISN 发完毕后 , 客 户 端 进 入ESTABLISHED 状态,当服务器端接收到这个包时,也进 入ESTABLISHED 状态, TCP 握手结束。
四次挥手表示 TCP 断开连接的时候,需要客户端和服务端总共发送 4 个包以确认连接的断开;客户端或服务器均可主动发起挥手动作(因为 TCP 是一个全双工协议),在 socket 编程中,任何一方执行 close() 操作即可产生挥手操作。
单工:数据传输只支持数据在一个方向上传输
半双工:数据传输允许数据在两个方向上传输,但是在某一时刻,只允许在一个方向上传输,实际上有点像切换方向的单工通信
全双工:数据通信允许数据同时在两个方向上传输,因此全双工是两个单工通信方式的结合,它要求发送设备和接收设备都有独立的接收和发送能力
假设客户端想要关闭连接,客户端发送一个 FIN 标志位置为 1 的包,表示自己已经没有数据 可以发送了,但是仍然可以接受数据。 发送完毕后,客户端进入 FIN_WAIT_1 状态。
服务器端确认客户端的 FIN 包,发送一个确认包,表明自己接受到了客户端关闭连接的请求, 但还没有准备好关闭连接。 发送完毕后,服务器端进入 CLOSE_WAIT 状态,客户端接收到这 个确认包之后,进入 FIN_WAIT_2 状态,等待服务器端关闭连接。
服务器端准备好关闭连接时,向客户端发送结束连接请求, FIN 置为 1。 发送完毕后,服务器 端进入 LAST_ACK 状态,等待来自客户端的最后一个 ACK。
客户端接收到来自服务器端的关闭请求,发送一个确认包,并进入 TIME_WAIT 状态,等待 可能出现的要求重传的 ACK 包。 服务器端接收到这个确认包之后,关闭连接,进入 CLOSED 状态。 客户端等待了某个固定时间(两个最大段生命周期, 2MSL, 2 Maximum Segment Lifetime) 之后,没有收到服务器端的 ACK,认为服务器端已经正常关闭连接,于是自己也关闭连接, 进入 CLOSED 状态。
为什么 TIME_WAIT 状态需要经过 2MSL(最大报文段生存时间)才能返回到 CLOSE状态?
答:虽然按道理,四个报文都发送完毕,我们可以直接进入 CLOSE 状态了,但是我们必须假象网络是不可靠的,有可以最后一个 ACK 丢失。所以 TIME_WAIT 状态就是用来重发可能丢失的 ACK 报文。
三次握手是因为因为当 Server 端收到 Client 端的 SYN 连接请求报文后,可以直接发送SYN+ACK 报文。其中 ACK 报文是用来应答的, SYN 报文是用来同步的。但是关闭连接时,当 Server 端收到 FIN 报文时,很可能并不会立即关闭 SOCKET(因为可能还有消息没处理完) ,所以只能先回复一个 ACK 报文,告诉 Client 端, "你发的 FIN 报文我收到了"。只有等到我 Server 端所有的报文都发送完了,我才能发送 FIN 报文,因此不能一起发送。故需要四步握手。
在三次握手过程中, Server 发送 SYN-ACK 之后,收到 Client 的 ACK 之前的 TCP 连接称为 半连接(half-open connect),此时 Server 处于 SYN_RCVD 状态,当收到 ACK 后, Server 转入 ESTABLISHED 状态。 SYN 攻击就是 Client 在短时间内伪造大量不存在的 IP 地址,并向 Server 不断地发送 SYN 包, Server 回复确认包,并等待 Client 的确认,由于源地址是不存 在的,因此, Server 需要不断重发直至超时,这些伪造的 SYN 包将产时间占用未连接队 列,导致正常的 SYN 请求因为队列满而被丢弃,从而引起网络堵塞甚至系统瘫痪。 SYN 攻 击时一种典型的 DDOS 攻击,检测 SYN 攻击的方式非常简单,即当 Server 上有大量半连接 状态且源 IP 地址是随机的,则可以断定遭到 SYN 攻击了
- 1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接
- 2、TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付
- 3、TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)- 4、每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信
- 5、TCP首部开销20字节;UDP的首部开销小,只有8个字节
- 6、TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道
- 1、应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同,应用程序产生的数据报长度将保持不变。 (将数据截断为合理的长度)
- 2、当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。 (超时重发)
- 3、当TCP收到发自TCP连接另一端的数据,它将发送一个确认。这个确认不是立即发送,通常将推迟几分之一秒。 (对于收到的请求,给出确认响应) (之所以推迟,可能是要对包做完整校验)
- 4、TCP将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP将丢弃这个报文段和不确认收到此报文段。 (希望发端超时并重发) (校验出包有错,丢弃报文段,不给出响应,TCP发送数据端,超时时会重发数据)
- 5、既然TCP报文段作为IP数据报来传输,而IP数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。如果必要,TCP将对收到的数据进行重新排序,将收到的数据以正确的顺序交给应用层。 (对失序数据进行重新排序,然后才交给应用层)
- 6、既然IP数据报会发生重复,TCP的接收端必须丢弃重复的数据。 (对于重复数据,能够丢弃重复数据)
- 7、TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。 (TCP可以进行流量控制,防止较快主机致使较慢主机的缓冲区溢出)
OSI 七层网络模型包含(应用层、表示层、会话层、传输层、网络层、数据链路层、物理层)、
TCP/IP 四层概念模型包含(应用层、传输层、网络层、数据链路层)
滑动窗口(Sliding window)是一种流量控制技 术。早期的网络通信中,通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道 网络拥塞状况,同时发送数据,导致中间节点阻塞掉包,谁也发不了数据,所以就有了滑动 窗口机制来解决此问题;发送和接受方都会维护一个数据帧的序列,这个序列被称作窗口
就是发送端允许连续发送的幀的序号表。 发送端可以不等待应答而连续发送的最大幀数称为发送窗口的尺寸。
接收方允许接收的幀的序号表,凡落在 接收窗口内的幀,接收方都必须处理,落在接收窗口 外的幀被丢弃。 接收方每次允许接收的幀数称为接收窗口的尺寸。
通过调整内核参数解决: 编辑文件/etc/sysctl.conf,加入以下内容:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后执行 /sbin/sysctl -p 让参数生效。
net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
net.ipv4.tcp_fin_timeout = 30 表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间。
net.ipv4.tcp_keepalive_time = 1200 表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为20分钟。
net.ipv4.ip_local_port_range = 1024 65000 表示用于向外连接的端口范围。缺省情况下很小:32768到61000,改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192 表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000 表示系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,TIME_WAIT套接字将立刻被清除并打印警告信息。
默 认为180000,改为5000。对于Apache、Nginx等服务器,上几行的参数可以很好地减少TIME_WAIT套接字数量,但是对于Squid,效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量,避免Squid服务器被大量的TIME_WAIT套接字拖死。
注:
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
设置这两个参数: reuse是表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接; recyse是加速TIME-WAIT sockets回收
同步阻塞I/O模式,数据的读取写入必须阻塞在一个线程内等待其完成。
采用 BIO 通信模型 的服务端,通常由一个独立的 Acceptor 线程负责监听客户端的连接。我们一般通过在while(true) 循环中服务端会调用
accept() 方法等待接收客户端的连接的方式监听请求,请求一旦接收到一个连接请求,就可以建立通信套接字在这个通信套接字上进行读写操作,
此时不能再接收其他客户端连接请求,只能等待同当前连接的客户端的操作执行完成, 不过可以通过多线程来支持多个客户端的连接
在活动连接数不是特别高(小于单机1000)的情况下,这种模型是比较不错的,可以让每一个连接专注于自己的 I/O 并且编程模型简单,也不用过多考虑系统的过载、限流等问题。线程池本身就是一个天然的漏斗,可以缓冲一些系统处理不了的连接或请求。但是,当面对十万甚至百万级连接的时候,传统的 BIO 模型是无能为力的。因此,我们需要一种更高效的 I/O 处理模型来应对更高的并发量。
NIO是一种同步非阻塞的I/O模型,在Java 1.4 中引入了NIO框架,对应 java.nio 包,提供了 Channel , Selector,Buffer等抽象。
NIO中的N可以理解为Non-blocking,不单纯是New。它支持面向缓冲的,基于通道的I/O操作方法。 NIO提供了与传统BIO模型中的 Socket 和 ServerSocket 相对应的
SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现,两种通道都支持阻塞和非阻塞两种模式。阻塞模式使用就像传统中的支持一样,比较简单,但是性能
和可靠性都不好;非阻塞模式正好与之相反。对于低负载、低并发的应用程序,可以使用同步阻塞I/O来提升开发速率和更好的维护性;对于高负载、高并发的(网络)应用,
应使用 NIO 的非阻塞模式来开发。
AIO 也就是 NIO 2。在 Java 7 中引入了 NIO 的改进版 NIO 2,它是异步非阻塞的IO模型。异步 IO 是基于事件和回调机制实现的,也就是应用操作之后会直接返回,不会堵塞在那里,当后台处理完成,操作系统会通知相应的线程进行后续的操作。
AIO 是异步IO的缩写,虽然 NIO 在网络操作中,提供了非阻塞的方法,但是 NIO 的 IO 行为还是同步的。对于 NIO 来说,我们的业务线程是在 IO 操作准备好时,
得到通知,接着就由这个线程自行进行 IO 操作,IO操作本身是同步的
IO多路复用模型是建立在内核提供的多路分离函数select基础之上的,使用select函数可以避免同步非阻塞IO模型中轮询等待的问题。
使用select函数进行IO请求和同步阻塞模型没有太大的区别,甚至还多了添加监视socket,以及调用select函数的额外操作,效率更差。但是,使用select以后最大的优势是用户可以在一个线程内同时处理多个socket的IO请求。用户可以注册多个socket,然后不断地调用select读取被激活的socket,即可达到在同一个线程内同时处理多个IO请求的目的。而在同步阻塞模型中,必须通过多线程的方式才能达到这个目的
fd:在 linux 中,内核把所有的外部设备都当成是一个文件来操作,对一个文件的读
写会调用内核提供的系统命令,返回一个 fd(文件描述符)。 而对于一个 socket 的读写也会有
相应的文件描述符,成为 socketfd
进程可以通过把一个或者多个 fd 传递给 select 系统调用,进程会阻塞在 select 操作 上,这样 select 可以帮我们检测多个 fd 是否处于就绪状态。 这个模式有二个缺点 就绪状态了, 那么当前进程需要线性轮询所有的 fd,也就是监听的 fd 越多,性能开销越
- 由于他能够同时监听多个文件描述符, 假如说有 1000 个,这个时候如果其中一个 fd 处于 大。
- 同时, select 在单个进程中能打开的 fd 是有限制的,默认是 1024,对于那些需要支持单机 上万的 TCP 连接来说确实有点少
linux 还提供了 epoll 的系统调用, epoll 是基于事件驱动方式来代替顺序扫描,因此性 能相对来说更高, 主要原理是,当被监听的 fd 中,有 fd 就绪时, 会告知当前进程具体哪一 个 fd 就绪,那么当前进程只需要去从指定的 fd 上读取数据即可 另外, epoll 所能支持的 fd 上线是操作系统的最大文件句柄,这个数字要远远大于 1024