TCP/IP三次握手、四次挥手、11种状态知识点整理

TCP三次握手建立连接 Tcp头部:   六个标志位中,我们要用到三个: SYN:SYNchronous,SYN= 1 表示这是一个连接请求或连接接受报文。在建立连接时用来进行同步序号(个人理解是,在建立连接的时候,提醒对方记录本方的起始序号)。当SYN=1而ACK=0时,表明这是一个连接请求报文段。对方若是同意建立连接,则应响应的报文段中使SYN=1、ACK=1。因此SYN=1表示该报文是一个连接请求报文或者是一个连接请求接收报文。 ACK:ACKnowledgment,确认号只有在该位设置为1的时候才生效,当该位为0是表示确认号无效。TCP规定,在TCP连接建立后所有传送的数据报文段ACK都必须设置为1。 FIN:FINish,当 FIN = 1 时,表明此报文段的发送方的数据已经发送完毕,并要求释放连接。   此外我们还需要用到序号和确认号: 序号:占4个字节,它的范围在0-2^32-1,序号随着通信的进行不断的递增,当达到最大值的时候重新回到0在开始递增。TCP是面向字节流的,在一个TCP连接中传送的字节流中的每一个字节都按照顺序编号。整个要传送的字节流的起始号必须在连接建立时设置。首部中的序列号字段指的是本报文段所发送的数据的第一个字节的序号。例如,一个报文序号是301,而携带的数据共有100字节。则表示本次报文中的序号是301,下一个报文的序号是401.重复一下,每一个报文的序号是该报文包含的字节中第一个字节的编号。 确认号:占4个字节,确认号,是对下一个想要接受的字节的期望,这里隐式确认了对上一个数据包的成功接收。如上例,在成功接收了序号为301的数据包,想要接收下一个数据包因为上个数据包包含100字节,所以此时的确认号应该是401,表示希望接收下一个序号是401的数据包。 三次握手过程:   过程描述: 首先由Client发出请求连接即 SYN=1 ACK=0  (请看头字段的介绍),TCP规定SYN=1时不能携带数据,但要消耗一个序号,因此声明自己的序号是 seq=x。 然后 Server 进行回复确认,即 SYN=1 ACK=1 seq=y,ack=x + 1。 再然后 Client 再进行一次确认,但不用SYN 了,这时即为 ACK=1,seq=x + 1,ack=y + 1。 为什么要进行三次握手(两次确认): 为什么A还要发送一侧确认呢?这主要是为了防止已失效的连接请求报文突然又传送到了B,因而产生错误。 所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。A发出连接请求,但因连接请求丢失而未收到确认。于是A再次重传一次连接请求。后来收到了确认建立了连接。数据传输完毕后,就释放了连接。A共发送了两个连接请求的报文段,其中第一个丢失,第二个到达了B。没有“已失效的连接请求报文段”。 现假定出现一种异常情况,即A发出的第一个连接请求报文段并没有丢失,而是在某些网络节点长时间滞留了,以致延误到连接释放以后的某个时间才到B。本来这是一个已失效的报文段。但是B收到此失效的连接请求报文段后,就误认为是A有发出一次新的连接请求。于是就向A发出确认报文段,同意建立连接。假定不采用三次握手,那么只要B发出确认,新的连接就建立了。 由于现在A并没有发出建立连接的请求,因此不会理睬B的确认,也不会向B发送数据。但B却以为新的运输连接已经建立了,并一直等待A发来数据。B的许多资源就这样白白浪费了。 采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下,A不会向B的确认发出确认。B由于收不到确认,就知道A并没有要求建立连接。 另一种解释: 这个问题的本质是, 信道不可靠, Read more…

Docker镜像存储结构与原理

Docker容器镜像存在哪儿,怎么存放? Docker容器在运行的过程中,只有小部分的数据可能需要写到容器可写层,因为大部分场景下,我们可以通过Docker volumes来写数据, 但是某些场景下,就是需要往容器可写层写数据,这就是Docker存储驱动Storage Driver出现的原因,这些存储驱动必须是采用层堆叠以及copy-on-write策略。 Docker采用可插拔的方式支持一些不同的存储驱动,存储驱动控制了镜像和容器在宿主机上如何管理以及存储。如果系统内核支持多种存储驱动,在没有明确设置 存储驱动时,Docker会根据优先级(btrfs,zfs,overlay2,aufs,overlay,devicemapper,vfs)顺序进行选择,排在前面的储存驱动并不总是会被Docker采用, 因为有些存储驱动对文件系统或者内核有硬性要求。 Docker支持如下storage driver: overlay2 Docker优先采用的存储驱动,对于已支持该驱动的Linux发行版,不需要任何进行任何额外的配置。 aufs Docker 18.06以下版本运行在Ubuntu 14.04以及kernel 3.13上,不支持overlay2,首选aufs。 devicemapper 默认的配置模式是loopback-lvm,但是在生产环境时Docker不推荐这种模式,它的性能非常差,我们需要将其配置成direct-lvm。 对于早期的CentOS和RHEL,devicemapper是推荐的存储驱动,因为它们对应的内核版本不支持overlay2,不过,我们现在版本的CentOS与RHEL均已支持overlay2。 btrfs and zfs Docker安装所在的宿主机文件系统是btrfs或者zfs,则Docker优先使用它们作为存储驱动,这些文件系统具有一些高级的选项配置,比如创建快照(snapshots)等。 vfs Docker不推荐用于生产环境,只用于测试,性能比较差,可能无法支持copy-on-write策略。 注意一些存储驱动要求使用特殊版本的文件系统,比如aufs仅在Ubuntu或者Debian系统被支持, 并且需要安装一些额外的依赖包,而btrfs仅在SLES被支持。 我们大多数人使用的应该都是Docker社区版本,下面列举了社区版Docker引擎在各Linux发行版中推荐的存储驱动。 Linux发行版 推荐的存储驱动 备选存储驱动 Ubuntu overlay2、 aufs(运行在内核3.13上的Ubuntu 14.04) overlay、devicemapper、 zfs、vfs Debian overlay2(Debian扩展版本)、 aufs、devicemapper(老版本) overlay、vfs CentOS overlay2 overlay、devicemapper、 zfs、vfs Fedora overlay2 overlay、devicemapper、 zfs、vfs Read more…