三次握手

1、简述osi七层模型和TCP/IP五层模型 TCP/IP与OSI最大的不同在于OSI是一个理论上的网络通信模型，而TCP/IP则是实际运行的网络协议; 1. OSI引入了服务、接口、协议、分层的概念，TCP/IP借鉴了OSI的这些概念建立TCP/IP模型。 2. OSI先有模型，后有协议，先有标准，后进行实践；而TCP/IP则相反，先有协议和应用再提出了模型，且是参照的OSI模型。 3. OSI是一种理论下的模型，而TCP/IP已被广泛使用，成为网络互联事实上的标准。 osi 七层模型包括： 物理层、数据链路层、网络层、传输层、应用层、会话层; TCP/I五层模型包括：网络接口层、网际层、传输层、应用层; 对应关系： 2、总结描述TCP三次握手四次挥手 客户端A向服务器B建立连接的三次握手： 1、A请求：A请求建立连接，发送序列号为X、标志位SYN=1的包，请求建立连接，此时，A进入同步已发送状态（SYN-SEND）； 2、B确认：B收到A发送的请求之后，若同意建立连接，发送序列号位Y、确认序号为X+1、SYN=1、ACK=1的包，此B进入同步已接收状态（SYN-RCVD）； 3、A确认：A收到B的确认包后，发送序列号为X+1、确认序号为Y+1、ACK=1的包，确认收到;将该报文发出后，A进入已连接状态（ESTABLISHED），B收到之后进入已连接状态（ESTABLISHED）

1、简述osi七层模型和TCP/IP五层模型 TCP/IP与OSI最大的不同在于OSI是一个理论上的网络通信模型，而TCP/IP则是实际运行的网络协议; 1. OSI引入了服务、接口、协议、分层的概念，TCP/IP借鉴了OSI的这些概念建立TCP/IP模型。 2. OSI先有模型，后有协议，先有标准，后进行实践；而TCP/IP则相反，先有协议和应用再提出了模型，且是参照的OSI模型。 3. OSI是一种理论下的模型，而TCP/IP已被广泛使用，成为网络互联事实上的标准。 osi 七层模型包括： 物理层、数据链路层、网络层、传输层、应用层、会话层; TCP/I五层模型包括：网络接口层、网际层、传输层、应用层; 对应关系： 2、总结描述TCP三次握手四次挥手 客户端A向服务器B建立连接的三次握手： 1、A请求：A请求建立连接，发送序列号为X、标志位SYN=1的包，请求建立连接，此时，A进入同步已发送状态（SYN-SEND）； 2、B确认：B收到A发送的请求之后，若同意建立连接，发送序列号位Y、确认序号为X+1、SYN=1、ACK=1的包，此B进入同步已接收状态（SYN-RCVD）； 3、A确认：A收到B的确认包后，发送序列号为X+1、确认序号为Y+1、ACK=1的包，确认收到;将该报文发出后，A进入已连接状态（ESTABLISHED），B收到之后进入已连接状态（ESTABLISHED）

1.校验和机制 TCP检验和的计算与UDP一样，检验范围包括TCP首部及数据部分,但是UDP的检验和字段为可选的，而TCP中是必须有的。计算方法为:在发送方将整个报文 段分为多个16位的段，然后将所有段进行反码相加，将结果存放在检验和字段中，接收方用相同的方法进行计算，如最终结果为检验字段所有位是全1则正确(UDP中为0是正确)，否则存在错误。 2.确认应答与序列号 TCP将每个字节的数据都进行了编号,这就是序列号。 序列号的作用: a、保证可靠性(当接收到的数据少了某个号的数据时，能马上知道) b、保证数据的按序到达 c、提高效率，可实现多次发送，一次确认 d、去除重复数据 数据传输过程中的确认应答处理、重发控制以及重复控制等功能都可以通过序列号来实现。 TCP通过确认应答机制实现可靠的数据传输。在TCP的首部中有一个标志位——ACK，此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认，当标志位ACK=1时，确认字段有效。进行确认时，确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文，则继续传输下一部分数据；而如果等待了一定时间还没有收到确认报文就会启动重传机制。 3. 超时重传 当报文发出后在一定的时间内未收到接收方的确认，发送方就会进行重传（通常是在发出报文段后设定一个闹钟，到点了还没有收到应答则进行重传）。

主要用到以下四个部分： Client API DB API 场景：登录 1、Client发起请求到API接口层 1.1用户在客户端输入登录信息，点击登录，发送请求 2、API接受用户发起的请求 2.1API对业务逻辑进行验证 2.1.1验证信息是否合法 3、API将用户输入的数据发送给DB crate、 read、 update 、delete 4、DB将返回的数据传给API 5、API返回成功或者失败的状态码返回给Client 6、客户端将返回的信息提示给用户 测试环境： 一、客户端 功能测试、自动化测试 二、接口层 接口测试 三、数据库 可以将开发人员的sql语句单独用例做性能测试 Http的请求流程 　　一次Http请求的 流程 　　客户端在输入域名后通过DNS服务器解析得到IP地址；得到IP地址后，通过三次握手进行TCP/IP连接；之后就进行通信。 　　TCP三次握手 　　TCP在建立连接的时候需要三次握手，第一次握手将Client标志位SYN设置为1，随机产生一个值seq=J；Server在收到Client传来的SYN时，必须进行确认(ack=J+1)，同时自己也发送一个SYN包，此Server进入SYN-RECV状态；Client在收到SYN+ACK包后向Server发送确认包ACK，发送完成后Client和Server进入连接状态，这就完成了三次握手，开始通信。 　

面试情景 一天，你进入了一个大厂面试。坐立不安之中，一个秃头中年男子，穿着一个发灰了的格子衬衫，戴着一副镜片厚9mm的眼镜，稳如磐石突然朝着你说到：“就是你这个小毛头来面试吧。” 心里一惊，这怕不是神仙级架构师。但还是故作镇定：“面试官您好，我是xxx…” 面试过程中……面试官随手抛来一句：“简单说说 TCP 三次握手吧。”。 简单说说？？？嗯，面试官人还不错。 再加上我面试前的精心准备，和饱读诗书的才华，和挥斥方遒的潇洒帅气，一定能深深折服他。 于是：“ TCP 三次握手很简单， 客户端首先生成一个 SYN 报文，随机生成一个 seq，发给服务端。 服务端生成一个 SYN 报文，随机生成一个 seq，返回一个 ACK（为客户端的 seq + 1），发给客户端。 客户端再返回一个ACK（为服务端的 seq + 1）和 seq（为先前的 seq + 1，也是服务端返回的 ACK 的值）。 三次握手就完成了。” 面试官再问： SYN 是啥 seq 是啥 ACK 是啥 为啥返回的 ACK = seq + 1 TCP 3 次握手可以携带数据吗 为啥一定要 “3” 次，2 次不行吗 为啥断开要 4 次，不能 3 次吗 如果报文段丢失怎么办 报文超长延迟怎么办 网络拥塞怎么办 这都啥？？？？？ “你回去等通知吧。” <瑟瑟发抖> 下面进入正题，如果上面的题你都理解，能够熟练回答，那对于 TCP

Node.js 网络通信 Node 是一个面向网络而生的平台，它具有事件驱动、无阻塞、单线程等特性，具备良好的可伸缩性，使得它十分轻量，适合在分布式网络中扮演各种各样的角色。同时 Node 提供的 API 十分贴合网络，适合用它基础的 API 构建灵活的网络服务。本课程的内容就是给大家介绍 Node 在网络通信编程方面的具体能力。 利用 Node 可以十分方便的搭建网络服务器。在 Web 领域，大多数的编程语言需要专门的 Web 服务器作为容器，如 ASP、ASP.NET 需要 IIS 作为服务器，PHP 需要打在 Apache 或 Nginx 环境等，JSP 需要 Tomcat 服务器等。但对于 Node 而言，只需要几行代码即可构建服务器，无需额外的容器。 Node 提供了 net、dgram、http、https 这4个模块，分别用于处理 TCP、UDP、HTTP、HTTPS，适用于服务器端和客户端。 网络通信相关概念 我们每天使用互联网，你是否想过，它是如何实现的？ 全世界几十亿台电脑，连接在一起，两两通信。上海的某一块网卡送出信号，洛杉矶的另一块网卡居然就收到了，两者实际上根本不知道对方的物理位置，你不觉得这是很神奇的事情吗？ 互联网的核心是一系列协议，总称为"互联网协议"（Internet Protocol Suite）。它们对电脑如何连接和组网，做出了详尽的规定

TCP是一个面向连接的协议。无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。下面将详细讨论一个 TCP连接是如何建立的以及通信结束后是如何终止的。 三次握手过程解析 请求端（通常称为客户）发送一个 SYN段指明客户打算连接的服务器的端口，以及初始序号（I S N）。这个S Y N段为报文段1。 服务器发回包含服务器的初始序号的 SYN报文段（报文段2）作为应答。同时，将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认。一个SYN将占用一个序号。 客户必须将确认序号设置为服务器的 ISN加1以对服务器的SYN报文段进行确认（报文段3）。 这三个报文段完成连接的建立。这个过程也称为三次握手（ three-way handshake）。 四次挥手过程解析 建立一个连接需要三次握手，而终止一个连接要经过 4次握手。这由T C P的半关闭（h a l f -c l o s e）造成的。既然一个T C P连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。 1.Client端发起中断连接请求，也就是发送FIN报文。 2.Server端接到FIN报文后，Client端没有数据要发给Server了，如果Server端还有数据发送，则不必急着关闭Socket，可以继续发送数据。 Server发送ACK，告诉Client接收到，并准备关闭

1. 计算机网络体系结构 计算机网络的体系结构有以上3种。 1. OSI的七层协议体系结构，概念清楚，理论完整，但复杂不实用； 2. TCP/IP体系结构，应用广泛。 3. 5层协议，综合OSI和TCP/IP的优点，相对简洁，用于原理学习。 各层的主要功能： 应用层（Application Layer）： 通过应用进程间的交互来完成特定网络应用，应用层协议定义的是应用进程间通信和交互的规则。应用层协议有：域名系统DNS、HTTP协议、邮件SMTP协议。应用层交互的数据成为报文（message）。 运输层（传输层，transport layer）： 负责向两台主机中进程之间的通信提供通用的数据传输服务。“通用”指多种应用可以使用同一个运输层服务。运输层主要使用的协议：1）TCP（Transmission Control Protocol）——提供面向连接的、可靠的数据传输服务，数据传输的单位是报文段（segment）；2）UDP（User Datagram Protocol）——提供无连接的、尽最大努力（best-effort）的数据传输服务（不保证数据传输的可靠性），数据传输的单位是用户数据。 网络层（network layer）： 负责为分组交换网上的不同主机提供通信服务。网络层使用的是无连接的网际协议IP（Internet Protocol）以及多种路由选择协议

一、TCP协议简介 TCP，全称Transfer Control Protocol，中文名为传输控制协议，它工作在OSI的传输层，提供面向连接的可靠传输服务。是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793 [1] 定义。 TCP的工作主要是建立连接，然后从应用层程序中接收数据并进行传输。TCP采用虚电路连接方式进行工作，在发送数据前它需要在发送方和接收方建立一个连接，数据在发送出去后，发送方会等待接收方给出一个确认性的应答，否则发送方将认为此数据丢失，并重新发送此数据。 工 作：与IP协议共同使用 下面我们来介绍一下TCP的报头结构和相关工作原理： TCP报头 TCP报头总长最小为20个字节，其报头结构如下图（图1）所示； 源端口：指定了发送端的端口 目的端口：指定了接受端的端口号 序号：指明了段在即将传输的段序列中的位置 确认号：规定成功收到段的序列号，确认序号包含发送确认的一端所期望收到的下一个序号 TCP偏移量：指定了段头的长度。段头的长度取决与段头选项字段中设置的选项 保留：指定了一个保留字段，以备将来使用 标志：SYN、ACK、PSH、RST、URG、FIN SYN： 表示同步 ACK： 表示确认 PSH： 表示尽快的将数据送往接收进程 RST： 表示复位连接 URG： 表示紧急指针 FIN： 表示发送方完成数据发送 窗口

最近工作中遇到一个问题，想把它记录下来，场景是这样的： 从上图可以看出，用户通过Client访问的是LVS的VIP， VIP后端挂载的RealServer是Nginx服务器。 Client可以是浏览器也可以是一个客户端程序。一般情况下，这种架构不会出现问题，但是如果Client端把请求发送给Nginx，Nginx的后端需要一段时间才能返回结果，超过1分30秒就会有问题，使用LVS作为负载均衡设备看到的现象就是1分30秒之后， Client和Nginx链接被断开，没有数据返回。原因是LVS默认保持TCP的Session为90s，超过90s没有TCP报文在链接上传输，LVS就会给两端发送RESET报文断开链接。LVS这么做的原因相信大家都知道一二，我所知道的原因主要有两点： 1.节省负载均衡设备资源，每一个TCP/UDP的链接都会在负载均衡设备上创建一个Session的结构， 链接如果一直不断开，这种Session结构信息最终会消耗掉所有的资源，所以必须释放掉。 2.另外释放掉能保护后端的资源，如果攻击者通过空链接，链接到Nginx上，如果Nginx没有做合适 的保护，Nginx会因为链接数过多而无法提供服务。 这种问题不只是在LVS上有，之前在商用负载均衡设备F5上遇到过同样的问题，F5的Session断开方式和LVS有点区别，F5不会主动发送RESET给链接的两端