计算机网路面试汇总

最新推荐文章于 2024-09-03 23:57:57 发布

wzEminem

最新推荐文章于 2024-09-03 23:57:57 发布

阅读量330

点赞数 1

分类专栏：计算机网络

本文链接：https://blog.csdn.net/wzEminem/article/details/95315254

版权

计算机网络专栏收录该内容

5 篇文章 0 订阅

订阅专栏

OSI七层模型 vs. TCP/IP 五层模型（有时候也说四层）及及各层协议？
- 七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层
- 四层或者五层：物理层、网络层（IP，ARP：反向地址解析协议）、传输层（TCP/UDP）、应用层（Http，https，ssl：加密套接字协议、smtp：邮件传输协议）
给定一个网址，访问这个网址经过了那些过程？涉及哪些协议？
- (1). 浏览器查询 DNS，获取域名对应的IP地址:具体过程包括
  - 浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。
  - 对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；
  - 如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。
  - 如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；（DNS,UDP协议）
- (2). 浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；（tcp协议）
- (3). TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；（http协议）
- (4).在2、3步中，在传输层使用到了tcp协议对http请求进行封装、在网络层中，ip协议将ip地址封装为ip数据报，才是用到ARP协议，找到ip地址对应的MAC地址
- (5).
  - 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
  - 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
- (6). 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
http报文：请求报文和响应报文？
- HTTP请求报文：一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成
  - 请求行：方法（GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT），URL字段、HTTP协议版本
    - get：？与URL隔开，&参数分开，有字符限制
    - psot：参数封装在请求数据中，没有大小限制
    - head：本质和get一样，但在相应中没有返回信息，只有头部信息
  - 请求头：请求头部通知服务器有关于客户端请求的信息
    - Cookie：存储于客户端扩展字段
    - Connection：连接方式(close 或 keepalive);(http长短连接)
- HTTP响应报文：状态行、响应头部、空行、响应数据
  - 状态行：http协议版本、状态码、状态码描述
  - 响应头部：与请求头部类似，为响应报文添加了一些附加信息
  - 常见状态码及原因短语
    - 3×× : 重定向，要完成请求必须进行进一步处理
      - 301 : 永久性转移
      - 302 ：暂时性转移
      - 304 ：已缓存（此一次访问连接的资源被保存在本地，response一个响应头来表示此资源，当下一次请求的时候，服务器请求到这个头，如果服务器这个资源没有变化，服务器的头也是一样的，服务器就不再返回该资源内容，将直接调用浏览器缓存）
    - 4×× : 客户端错误，请求不合法
      - 400：Bad Request,请求有语法问题
      - 403：拒绝请求
      - 404：客户端所访问的页面不存在
    - 5×× : 服务器端错误，服务器不能处理合法请求
      - 500 ：服务器内部错误
      - 502：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
      - 503 ：服务不可用，稍等
      - 504：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。
http的get和post方法：
- (1). 从功能上讲，GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；
- (2). 从REST服务角度上说，GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；
- (3). 从请求参数形式上看，GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的请求头中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII)；而POST请求会把提交的数据则放置在是HTTP请求报文的请求体中。
- (4). 就安全性而言，POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全。
- (5). 从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。
HTTP
- HTTP是一个简单的请求-响应协议，它通常运行在TCP之上
- 客户与服务器之间的HTTP连接是一种一次性连接，它限制每次连接只处理一个请求，当服务器返回本次请求的应答后便立即关闭连接，下次请求再重新建立连接。
- HTTP是一种无状态协议，即服务器不保留与客户交易时的任何状态。这就大大减轻了服务器记忆负担，从而保持较快的响应速度。
- HTTP是一种面向对象的协议。允许传送任意类型的数据对象。
- 从技术上讲是客户在一个特定的TCP端口（端口号一般为80）上打开一个套接字。如果服务器一直在这个周知的端口上倾听连接，则该连接便会建立起来。然后客户通过该连接发送一个包含请求方法的请求块。
HTTP and HTTPS
- Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：
  - 端口不同：Http与Http使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
  - 资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；
  - 开销：Https通信需要证书，而证书一般需要向认证机构购买；
  - Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。
HTTP1.0和HTTP1.1的一些区别
- 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
- 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
- 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
- Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
- 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
http协议上可以建立多少个tcp连接
- 在 HTTP/1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接。但是这样每次请求都会重新建立和断开 TCP 连接，代价过大。
- 持久连接：既然维持 TCP 连接好处这么多，HTTP/1.1 就把 Connection 头写进标准，并且默认开启持久连接，除非请求中写明 Connection: close，那么浏览器和服务器之间是会维持一段时间的 TCP 连接，不会一个请求结束就断掉。
- 如果维持连接，一个 TCP 连接是可以发送多个 HTTP 请求的。
- 维持和服务器已经建立的 TCP 连接，在同一连接上顺序处理多个请求。
- 和服务器建立多个 TCP 连接。Chrome 最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别。
HTTP的无状态
- 无状态：
  - 1.协议对于事务处理没有记忆能力
  - 2.对同一个url请求没有上下文关系
  - 3.每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求时无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况
  - 4.服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器
- 标准的http协议指的是不包括cookies，session，application的http协议：无状态的
如果禁用cookie你有什么办法可以保存用户的登录状态吗
- (1)如果用户禁止cookie，服务器仍会将sessionId以cookie的方式发送给浏览器，但是，浏览器不再保存这个cookie(即sessionId)了。
- (2)如果想继续使用session，需要采取其他方式来实现sessionId的跟踪。可以使用url重写来实现sessionId的跟踪。
- (3)url重写
  - 如果浏览器不支持Cookie或用户阻止了所有Cookie，可以把会话ID附加在HTML页面中所有的URL上，这些页面作为响应发送给客户。这样，当用户单击URL时，会话ID被自动作为请求行的一部分而不是作为头行发送回服务器。这种方法称为URL重写(URL rewriting)。
TCP vs UDP
- 区别：
  - 1.基于面向连接与无连接。因为每个连接都会占用系统的CPU、内存等硬件资源，所以对系统资源的要求TCP较多UDP少；并且tcp是一对一的，udp是一对一，一对多，多对一，多对多通信。
  - 2.
    - 字节流：应用程序对数据的发送和接受没有边界限制，即发送端执行的写操作次数和接受端的读操作次数没有任何数量关系，并且send只是将数据写进发送缓冲区，recv只是从输出缓冲区中获取数据。【因为如果发送端应用程序连续执行写操作，tcp先将数据放入TCP发送缓冲区中，等到缓冲区真正发送数据时，数据可能被封装了一个或多个TCP报文段发出，即TCP发出的tcp报文段个数和执行的写操作次数没有关系。而接受端收到一个或多个TCP报文段，先将他们携带的数据按序号依次放到接受缓冲区中，通知应用进程接受。应用程序可以一次全部读出，也可以分几次读出，这取决于应用程序的缓冲区大小，即TCP模块接受的报文段个数和读操作次数没关系。】
    - 数据报：sendto发送数据和对端recvfrom接受数次数相等，因此UDP保留了应用层数据的边界。【发送端应用程序每执行写操作一次，UDP模块就将它封装成一个数据报发送了。接收端必须及时对每个udp数据报执行读操作并且一次接受完，否则不读数据会丢包，或者不读完整数据会被截断发生数据丢失。】
  - 3.tcp是可靠传输，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;udp是不保证可靠交付。
    - 可靠性体现在：应用程序将数据发送给TCP，然后TCP把数据流分区成适当长度的报文段（通常受该计算机连接的网络的数据链路层的最大传输单元（ MTU）的限制）之后TCP把结果包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。TCP为了保证不发生丢包，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认（ACK）；如果发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据包就被假设为已丢失将会被进行重传。TCP用一个校验和函数来检验数据是否有错误；在发送和接收时都要计算校验和。
    - 具体体现为：
      - 1．应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据长度将保持不变。由TCP传递给IP的信息单位称为报文段或段。【在TCP三次我握手的前两次握手中（也就是两个SYN报文段中），通过一个“协商”的方式来告知对方自己期待收到的最大报文段长度（MSS），结果使用通信双发较小的MSS最为最终的MSS。在SYN=1的报文段中，会在报文段的选项部分来指定MSS大小（相当于告知对方自己所能接收的最大报文段长度）。在后续通信双发发送应用层数据之前，如果发送数据超过MSS，会对数据进行分段】。
      - 2.当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。当TCP收到发自TCP连接另一端的数据，它将发送一个确认。TCP有延迟确认的功能，在此功能没有打开，则是立即确认。功能打开，则由定时器触发确认时间点。
      - 3.TCP有超时重传机制，如果没有收到对端对于发送报文的确认，则会重传一份。如果发送端在合理的往返时延（RTT）内未收到确认，那么对应的数据包就被假设为已丢失将会被进行重传。
      - 4．TCP将保持它首部和数据的检验和。CRC对TCP整个数据报进行校验（头部和数据部分都会校验）用一个校验和函数来检验数据是否有错误；在发送和接收时都要计算校验和。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。
      - 5．既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序、重复，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序、整理，将收到的数据以正确的顺序交给应用层。【在同一次传输的同一个方向上每个TCP报文都有唯一的标识(序号），也保证了传送到接收端实体的包的按序接收。然后接收端对已成确认功收到的包发回一个相应的ACK；若重复TCP的接收端必须丢弃重复的数据。】
      - udp和ip协议都是提供不可靠服务，它们需要上层协议来处理数据确认和超时重传。
    - 4.TCP有拥塞控制机制;UDP没有拥塞控制，适合媒体通信；
    - 5.TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大；
TCP vs UDP区别应用场景
- TCP的优点：可靠，稳定 TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。
- TCP的缺点：慢，效率低，占用系统资源高，易被攻击。 TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。而且，因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。
- UDP的优点：快，比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击……
- UDP的缺点：不可靠，不稳定因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。
- 基于上面的优缺点，
  - 使用TCP：当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。在日常生活中，常见使用TCP协议的应用如下：浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输 ………… 什
  - 使用UDP：当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。比如，日常生活中，常见使用UDP协议的应用如下： QQ语音 QQ视频 TFTP ……
TCP和UDP分别对应的常见应用层协议
- 1). TCP对应的应用层协议
  - FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。
  - Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是-纯字符界面的，支持BBS的服务器将23端口打开，对外提供服务。
  - SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。
  - POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。
  - HTTP：从Web服务器传输超文本到本地浏览器的传送协议。
- 2). UDP对应的应用层协议
  - DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
  - SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
  - TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。
TCP协议如何来保证传输的可靠性
- TCP提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。
- 对于可靠性，TCP通过以下方式进行保证：——三次握手、超时重传、滑动窗口、拥塞控制
  - 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
  - 对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
  - 丢弃重复数据：对于重复数据，能够丢弃重复数据；
  - 应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
  - 超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
  - 流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。
TCP的拥塞控制，具体过程是怎么样的？UDP有拥塞控制吗？如何解决？
- TCP拥塞控制机制：
  - 慢开始：要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小
  - 拥塞避免：算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
  - 快重传：要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。由于不需要等待设置的重传计时器到期，能尽早重传未被确认的报文段，能提高整个网络的吞吐量。
  - .快恢复：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh（慢开始门限）减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。
- UDP没有流量控制和拥塞控制，所以在网络拥塞时不会是源主机发送速率降低（对实时通信很有用，比如QQ电话，视频会议等）
TCP的流量控制与滑动窗口
- 如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。
- TCP的流量控制是利用滑动窗口机制实现的，接收方在返回的ACK中会包含自己的接收窗口的大小，以控制发送方的数据发送。
三次握手四次挥手
- TCP连接终止：
  - TCP报文格式
    - （1）序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
    - （2）确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
    - （3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
      - （A）URG：紧急指针（urgent pointer）有效。
      - （B）ACK：确认序号有效。
      - （C）PSH：接收方应该尽快将这个报文交给应用层。
      - （D）RST：重置连接。
      - （E）SYN：发起一个新连接。
      - （F）FIN：释放一个连接。
    - 需要注意的是：
      - （A）不要将确认序号Ack与标志位中的ACK搞混了。
      - （B）确认方Ack=发起方Req+1，两端配对。
  - 三次握手
    - 1）主机A向主机B发送TCP连接请求数据包，其中包含主机A的初始序列号seq(A)=x。（其中报文中同步标志位SYN=1（同步请求），表示这是一个TCP连接请求数据报文；序号seq=x，表明传输数据时的第一个数据字节的序号是x）；
    - 2）主机B收到请求（SYN=1）后，会发回连接确认数据包。（1、其中确认报文段中，标识位SYN=1，ACK=1，表示这是一个TCP连接响应数据报文，并含主机B的初始序列号seq(B)=y，以及主机B对主机A初始序列号的确认序号Ack(B)=seq(A)+1=x+1）
    - 3）第三次，主机A收到主机B的确认报文后（ACK=1，Ack=x+1），如果正确则将标志位ACK置为1，Ack=y+1，并将该数据包发送给主机B，主机B检查ack是否为y+1，ACK是否为1，如果正确则连接建立成功
  - 四次挥手
    - 所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：
    - 由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。
    - 关闭客户端到服务器的连接
      - （1）第一次挥手：Client发送一个FIN=1，初始序列号seq(A)=x，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
      - （2）第二次挥手：Server收到FIN=1后，确认序号有效，发送一个ACK给Client，确认序号为收到序号seq（A）+1=x+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
    - 关闭服务器到客户端的连接
      - （3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
      - （4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
  - SSL四次握手的过程
    - 1、客户端发出请求：首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。
    - 2、服务器回应：服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。
    - 3、客户端回应：客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
    - 4、服务器的最后回应：服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
      - （1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
      - （2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
    - 至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。
  - 为什么TCP链接需要三次握手
    - 为了防止已失效的链接请求报文突然又传送到了服务端，因而产生错误。
    - 客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达Server。这是，Server误以为这是Client发出的一个新的链接请求，于是就向客户端发送确认数据包，同意建立链接。若不采用“三次握手”，那么只要Server发出确认数据包，新的链接就建立了。由于client此时并未发出建立链接的请求，所以其不会理睬Server的确认，也不与Server通信；而这时Server一直在等待Client的请求，这样Server就白白浪费了一定的资源。若采用“三次握手”，在这种情况下，由于Server端没有收到来自客户端的确认，则就会知道Client并没有要求建立请求，就不会建立链接。
TCP断开连接，讲讲Close_Wait。Timewait
- Timewait是主动关闭的一端在本端已经关闭的前期下，收到对端的关闭请求（FIN报文段）并且将ACK发送出去后所处的状态，这种状态表示：双方都已经完成工作，只是为了确保迟来的数据报能被识别并丢弃；可靠的终止TCP连接。这种状态下客户端连接要等一段2MSL（报文段最大生存时间【2min】）的时间，才能完全关闭。
  - 具体存在原因：①可靠的终止tcp连接。假如用于确认服务器结束报文段的tcp报文段7丢失了，那服务器将重发结束报文段。所以客户端需要停留在一个状态处理多次收到的服务器结束报文段。（也就是向服务器发送确认报文段）。否则，客户端将发送复位报文段给服务器，服务器认为这是一个错误。
  - ②保证让迟来的tcp报文段有足够时间被识别和丢弃。因为如果没有timewait状态，应用程序可以立即建立一个和刚关闭的相似的链接。这个连接可能接受原来连接的携带应用数据的tcp报文段（迟来的报文段）。因此我们此时不应该用此链接的端口号建立新连接，设为timewait状态。然后等待2MSL（保证网络的两个传输方向上迟到的报文段都消失了【被中转路由器丢弃】时间去使迟来的报文段被识别丢弃！
- CLOSE_WAIT是被动关闭的一端在接收到对端关闭请求（FIN报文段）并且将ACK发送出去后所处的状态，这种状态表示：收到了对端关闭的请求，但是本端还没有完成工作，还未关闭。
路由器和交换机的区别：
- 交换机用于同一网络内部数据的快速传输转发决策通过查看二层头部完成转发不需要修改数据帧工作在 TCP/IP 协议的二层 —— 数据链路层工作简单，直接使用硬件处理
- 路由器用于不同网络间数据的跨网络传输转发决策通过查看三层头部完成转发需要修改 TTL ，IP 头部校验和需要重新计算，数据帧需要重新封装工作在 TCP/IP 协议的三层 —— 网络层工作复杂，使用软件处理。
RPC协议（经常和Dubbo一起问）
- RPC（Remote Procedure Call Protocol）——远程过程调用协议
- dubbo就是一种RPC框架。他的通讯协议是RPC协议，dubbo以RPC框架为主，主要修改了tcp协议，更快。而springcloud主要就是全家桶，它使用http协议传输的，性能不如dubbo（dobbo+zookeeeper+dubbo.admin(War包)
  - 1、被远程调用的接口，需要在zookeeper中进行注册；
  - 2、需要远程调用的服务在zookeeper中声明自己需要的接口；
  - 3、zookeeper将已经注册的接口通知给需要的服务；
- Spring Cloud也是一种RPC框架，他的通讯协议是http restful 协议；REST协议，它基于HTTP的协议，是一种明确构建在客户端/服务端体系结构上的一种风格