7层网络架构&TCP(三次握手和四次挥手)

为什么端口号只有65535个?TCP/UDP专门存放端口号的字段是占两个字节，端口0代表动态分配一个1-65535的端口号所以0不算，可用端口数即2的16次方-1=65535，

一层层加工装包

font color=\"ff0000\

基础消息

TCP包首部

TCP:TCP提供的是一种可靠的数据流服务，数据有可能被拆分后发送，那么采用超时重传机制是和应答确认机制是组成TCP可靠传输的关键设计。

客户端A

数据链路层

以太网首部

客户端

接收FIN后

第一次握手span style=\"font-size: inherit;\

(1)某个应用进程首先调用close，我们称该端执行主动关闭（active close)。该端的TCP于是发送一个FIN分节，表示数据发送完毕，应用进程进入FIN-WAIT-1（终止等待1）状态。(2）接收到这个FIN的对端执行被动关闭(passive close)，发出确认报文。因为FIN的接收意味着接收端应用进程在相应连接上再无额外数据可接收，接收端进入了CLOSE-WAIT（关闭等待）状态，这时候处于半关闭状态，即主动关闭端已经没有数据要发送了，但是被动关闭端若发送数据，主动关闭端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。主动关闭端收到确认报文后进入FIN-WAIT-2（终止等待2）状态。(3)一段时间后，被动关闭的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN，表示它也没数据需要发送了。(4)接收这个最终FIN的原发送端TCP（即执行主动关闭的那一端）确认这个FIN发出一个确认ACK报文，并进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命/最长分节生命期max segement lifetime，MSL是任何IP数据报能够在因特网中存活的最长时间，任何TCP实现都必须为MSL选择一个值。RFC 1122[Braden 1989]的建议值是2分钟，不过源自Berkelcy的实现传统上改用30秒这个值。这意味着TIME_WAIT状态的持续时间在1分钟到4分钟之间）的时间后，当主动关闭端撤销相应的TCB后，才进入CLOSED状态。(5)被动关闭端只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，被动关闭端结束TCP连接的时间要比主动关闭端早一些。

解析

发送方在发送数据包（假设大小为10 byte）时，同时送上一个序号( 假设为500)，那么接收方收到这个数据包以后，就可以回复一个确认号（510 = 500 + 10）告诉发送方“我已经收到了你的数据包，你可以发送下一个数据包，序号从511开始”。

客户端B

举例说明

数据格式转换和数据加密

延缓TCB分配方法

应用层

第四次挥手(发送ACK报文)

区分网络通信是否是同一个

传输层

IP包首部

应用层（http、telnet、ftp、dns）

用于识别同一个计算机进行通信的不同应用程序，因此也可以叫做程序地址。

第二次挥手(发送ACK报文)

CLOSED状态

建立、管理和维护 端到端的链接。TCP(可靠、链接)/UDP(不可靠无连接，多用于看网络视频)

源IP+源端口号+目标IP+目标端口号+网络协议号

不进行连接

ESTABLISHED同步已建立链接

网络层

提供介质访问和链路管理(MAC)

网卡、网线

TIME-WAIT（时间等待）状态

发送FIN报文后

一般的做完第一次握手之后，服务器就需要为该请求分配一个TCB（连接控制资源），通常这个资源需要200多个字节。延迟TCB的分配，当正常连接建立起来后再分配TCB则可以有效地减轻服务器资源的消耗

装包

缺陷

TCP的三次握手的漏洞-SYN洪泛攻击

三次握手总结

建立、管理和维护 会话

计算机网络体系结构

其实四次挥手，与三次握手一样。只是服务端客户端进行关闭时，不是立即就关闭的，需要等一段时间，因此才需要四次。区别在于服务端发送确认后，需要等一段时间才发送FIN报文。三次握手的服务端是直接进行确认并发送同步请求的。①客户端发送给服务端FIN报文，告诉他要断开。并发送seq_no=x②服务端接收到FIN报文后，进行确认，发送ACK报文，并发送确认编码ack_no=x+1.③服务端过了一段时间处理完数据后，自己调用close。并发送FIN报文，告诉客户端我也要关闭了。④客户端接收到服务端的FIN报文后，回应给服务端ACK报文。服务端接收到这个报文后，立即关闭，进入close状态。而客户端会再经过一段时间2*MSL，进入close状态

FIN-WAIT-1（终止等待1）状态

IP选址和路由选择

上面看不懂的可以看这里，我将个人的理解加入解析，一看就懂

FIN-WAIT-2（终止等待2）状态

三次握手中有一个第二次握手，服务端向客户端应答请求，应答请求是需要客户端IP的，而且因为握手过程没有完成，操作系统使用队列维持这个状态，记录没有完成三次握手的客户端列表。攻击者就会通过伪造大量的客户端ip来进行请求链接，第一次握手后，服务端对这些大量请求进行第二次握手的回应，导致列表占满。

细节

长链接

三次握手详细过程

使用防火墙

物理层

短链接

应用程序通过http协议进行封包

seq_no和ack_no意义

接收到服务端FIN报文后进入，发送ACK报文，并进入

TCP详解

表示层

某个应用进程首先调用close

第三次挥手(发送服务端自己的FIN报文)

主动关闭端收到服务端确认报文后

被动关闭的应用进程将调用close关闭它的套接字

一层层解析降包

为了实现可靠数据传输，TCP协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤

三次握手是指建立一个TCP 连接时需要客户端和服务器端总共发送三个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，所以网络通信中，发起连接的一方我们称为客户端，接收连接的一方我们称之为服务端。

防火墙在确认了连接的有效性后，才向内部的服务器（Listener）发起SYN请求

解决方案

网络交互链路：

ESTAB_LISHED同步已建立链接

SYN_SENT同步已发送

只要收到了客户端发出的确认，立即进入CLOSED状态

服务端

①首先客户端发一个同步的请求，所以报文中SYN标记为1代表此次是同步请求。和序号seq_no=x，是为了告诉服务端客户端往服务端同步从x开始。②然后服务端接收到同步请求后，需要确认所以报文中ACK标记为1(表示确认收到客户端的同步请求)，并将ack_no设置为客户端发来的seq+1(告诉客户端我回应的是序号为x的那个同步消息)。服务端也需要给客户端同步，因此此次报文又将SYN标记为1，并加了新的seq标号为y，告诉客户端服务端往客户端同步的序号从y开始。最终服务端回应给客户端的报文就是确认报文+请求同步报文。③客户端收到服务端的确认，完成客户端往服务端同步的请求确认。又收到了服务端的同步请求，因此需要回应给服务端确认报文。因此此次报文是将ACK置为1(表示确认同步)，并发送seq_no=y+1(代表此次确认的是序号为y的请求)

TCP报文

为应用层提供服务

作用

CLOSE-WAIT（关闭等待）状态

OSI参考模型

网络路由器等

2∗MSLlinux默认配置的MSL=60s

TCP四次挥手

知名端口号：协定的一部分端口号固定。比如FTP服务器:21SSH服务器:22

第三次握手(发送ACK报文)

端口号

第一次握手(发送SYN报文)

UDP

SYNACK标志位

LISTEN收听

     FIN=1，seq_no=随机数字y

四次挥手即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。由于TCP连接是全双工的，因此，每个方向都必须要单独进行关闭。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。

主动关闭发送FIN

第二次握手(发送SYN、ACK报文)

第一次挥手(发送FIN报文)

会话层

UDP：1、面向无连接的通讯协议。2、通讯时，不需要接收方的确认，属于不可靠传输。3、因为不需要确认，因此传输速度快，但容易丢包。

TCP

TCP/IP五层模型

SYN_REVD同步已收到