计算机网络

计算机网络

七层/五层模型

七层模型(OSI)为ISO标准指定的,五层模型通常是指TCP/IP五层模型。

OSI 功能 协议
物理层 定义物理设备标准，完成比特流在物理设备上的传输
数据链路层 点对点之间可靠连接，差错控制，建立维持拆除,传输的是帧 ARQ,PPP,CSMA/CD
网络层 路由选择，网络地址划分，拥塞控制，网络互联,传输的是ip数据包 IP,ARP,OSPF,RIP,ICMP,BGP
传输层 提供面向连接或无连接的数据传输服务,端对端传输,传输的是数据段 TCP,UDP
会话层 建立维护终止会话
表示层 协商应用程序交互的数据格式
应用层 为网络应用提供协议支持和服务,传输的是报文 HTTP,DNS,SSH,FTP,DHCP

TCP连接与释放

TCP连接时三次握手

三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。
进行三次握手：

  • 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。此时客户端处于 SYN_SENT 状态。

    首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

  • 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

  • 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

  • 为什么要三次握手而不是两次?

    第一次握手,客户端向服务端发送网络包,服务端可以得出结论:客户端发送正常,服务端接收正常；第二次握手,服务端发送网络包,客户端得出结论:服务端发送/接收正常,客户端发送/接收正常,但服务端并不能知道客户端接收是否正常,第三次握手,客户端向服务端发送网络包,服务端得出结论:客户端和服务端发送/接收都正常。

    如果采用两次握手就会出现已经失效的连接.比如客户端向服务端发送一个请求连接,但因为网络波动导致此连接丢失,于是客户端重新发送一次请求连接,当客户端和服务端通信结束后,之前那个丢失的连接到达了服务端,如果只采用两次握手的话,那么服务端此时回应无效的连接,建立了一次无效的连接,耗费资源。

  • 什么是半连接队列?

    服务器第一次收到客户端的连接时，状态变为SYN_RCVD,此时双方还未建立连接,服务器会把此种连接的请求放到一个队列里,称为半连接状态,与之对应的是已经建立连接的全连接队列,但队列满了之后可能会有丢包.

  • ISN(Initial Sequence Number)是固定的吗？

    三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

  • 三次握手过程中可以携带数据吗？

    第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据,为什么这样呢?大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

  • SYN攻击是什么？

    服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

    1
    2
    #linux检测检测是否被syn攻击
    netstat -n -p TCP | grep SYN_RECV

    常见的防御 SYN 攻击的方法有如下几种：

    • 缩短超时（SYN Timeout）时间
    • 增加最大半连接数
    • 过滤网关防护
    • SYN cookies技术

TCP释放时四次挥手

建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。TCP 连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，客户端或服务端均可主动发起挥手动作。刚开始双方都处于ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

  • 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
    即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
  • 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
    即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
  • 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
    即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
  • 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
    即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

  • 为什么需要四次挥手?

    因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

  • 2MSL等待状态

    TIME_WAIT状态也成为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime），它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。对一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）。这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。

  • 四次挥手释放连接时，等待2MSL的意义?

    为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

    • 保证客户端发送的最后一个ACK报文段能够到达服务端。

      这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，若客户端在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。

    • 防止“已失效的连接请求报文段”出现在本连接中。

      客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

  • 为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态？

    理论上，四个报文都发送完毕，就可以直接进入CLOSE状态了，但是可能网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

  • TCP 协议如何保证可靠传输？

    (1）应用数据被分割成 TCP 认为最适合发送的数据块。
    （2）TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
    （3）校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
    （4）TCP 的接收端会丢弃重复的数据。
    （5）流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
    （6）拥塞控制： 当网络拥塞时，减少数据的发送。
    （7）停止等待协议 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

  • TCP怎么解决拥塞控制？

    1. 慢开始

      在TCP刚刚连接好并开始发送TCP报文段时，先令拥塞窗口cwnd = 1，即一个最大报文段长度MSS。每收到一个对新报文段的确认后，将cwnd 加1，即增大一个MSS。用这样的方法逐步增大发送方的拥塞窗口 cwnd，可使分组注入网络的速率更加合理。

    2. 拥塞避免算法

      拥塞避免算法的做法如下：发送端的拥塞窗口cwnd每经过一个往返时延RTT就增加一个MSS的大小，而不是加倍，使cwnd按线性规律缓慢增长（即加法增大)，而当出现一次超时(网络拥塞)时，令慢开始门限ssthresh等于当前cwnd的一半（即乘法减小)。

    3. 快重传

      快重传技术使用了冗余ACK来检测丢包的发生。同样，冗余ACK也用于网络拥塞的检测（丢了包当然意味着网络可能出现了拥塞)。快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。当发送方连续收到三个重复的ACK报文时，直接重传对方尚未收到的报文段，而不必等待那个报文段设置的重传计时器超时。

    4. 快恢复

      快恢复算法的原理如下：发送端收到连续三个冗余ACK(即重复确认）时，执行“乘法减小”算法，把慢开始门限ssthresh设置为出现拥塞时发送方cwnd的一半。与慢开始（慢开始算法将拥塞窗口cwnd 设置为1)的不同之处是，它把cwnd 的值设置为慢开始门限ssthresh改变后的数值，然后开始执行拥塞避免算法(“加法增大”)，使拥塞窗口缓慢地线性增大。

  • 粘包和拆包发生原因？粘包和拆包解决策略?

    1、要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包；
    2、要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包；
    3、待发送数据大于最大报文长度，TCP在传输前将进行拆包；
    4、接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包；

    消息定长：发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从缓冲区中读取固定长度的数据，这就自然而然的把每个数据包拆分开来；

    设置消息边界：服务端从网络流中按消息边界分离出消息内容，比如在数据包末尾增加回车换行符进行分割；

    将消息分为消息头和消息体：消息头中包含表示消息总长度（或者消息体长度）的字段，消息体是要读取的内容；
    更复杂的应用层协议

TCP/UDP

  • 传输效率而言

    TCP面向连接,通过三次握手先建立连接,四次挥手释放连接,UDP是无需连接的,发送数据之前不需要建立连接,因此UDP的传输效率较高。

  • 可靠性而言

    TCP是可靠的通信方式,通过TCP连接传送的数据,TCP通过超时重传、数据校验等方式来确保数据无差错,不丢失,不重复,按序到达，而UDP不保证可靠交付,可能会出现丢失、重复现象。

  • 传输数据格式而言

    TCP是面向字节流进行传输,而UDP是面向数据包进行传输

  • 传输模式而言

    TCP是点对点进行传输的,UDP可以一对一,一对多,多对多进行传输。

  • 开销而言

    TCP的首部为20个字节,UDP的首部为8个字节,TCP的开销较大。

HTTP

HTTP协议是超文本传输协议的缩写，是用于从万维网传输超文本到浏览器的传输协议。HTTP基于TCP/IP通信协议来传递数据（HTML文件，图片文件、查询结果等）。它不涉及数据包（packet）传输，主要规定了客户端和服务器之间的通信格式，默认使用80端口。

  • 特点

    1. 无连接：无连接是指限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。这种方式可以节省传输时间。
    2. 无状态：HTTP协议自身不对请求和响应之间的通信状态进行保存，任何两次请求之间都没有依赖关系。（每次请求都是独立的，与前面的请求和后面的请求都没有直接联系。协议本身不保留之前一切的请求或响应报文的信息。）

  • 请求方法

    • GET: get是将请求放在URL中的，GET请求是可以缓存的，我们可以从浏览器历史记录中查找到GET请求，还可以把它收藏到书签中;且GET请求有长度限制；只能通过url进行编码；不安全，不能用来传递敏感信息。
    • POST: 用于将数据发送到服务器以创建或更新资源。post请求将请求参数保存在request body中;POST请求永远不会被缓存，且对数据长度没有限制;我们无法从浏览器历史记录中查找到POST请求；支持多种编码格式；更安全，适合传递敏感信息。
    • DELETE：用来删除指定的资源，它会删除目标资源的所有当前内容。（用于删除）
    • PUT: 用于将数据发送到服务器以创建或更新资源，它可以用上传的内容替换目标资源中的所有当前内容。（用于更新）

  • 状态码

    1XX——信息提示，服务器收到请求，需要请求者继续执行操作；

    2XX——成功，操作被成功接收并处理；

    3XX——重定位，需要进一步的操作以完成请求；

    4XX——客户端错误，请求包含语法错误或无法完成请求；

    5XX——服务器错误，服务器在处理请求的过程中发生了错误。

    常见状态码：

    100：继续，客户端应继请求；
    200：请求成功；
    301：资源（网页等）被永久转移到其他 URL；
    302：暂时重定向；
    403: Forbidden —禁止访问；
    404：请求的资源（网页等）不存在；
    500：内部服务器错误。

  • 版本

    1. http1.0

      HTTP1.0默认使用 Connection:cloose，浏览器每次请求都需要与服务器建立一个 TCP 连接，服务器处理完成后立即断开 TCP 连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。

    2. http1.1

      HTTP1.1默认使用 Connection:keep-alive（长连接），避免了连接建立和释放的开销；通过 Content-Length 字段来判断当前请求的数据是否已经全部接受。不允许同时存在两个并行的响应。

      • http1.1的缺陷

        高延迟，带来页面加载速度的降低。（网络延迟问题只要由于队头阻塞，导致宽带无法被充分利用）

        无状态特性，带来巨大的Http头部。

        明文传输，不安全。

        不支持服务器推送消息。

    3. http2.0

      • HTTP2.0新特性

        二进制传输

        http2.0将请求和响应数据分割为更小的帧，并且它们采用二进制编码(http1.0基于文本格式)。多个帧之间可以乱序发送，根据帧首部的流表示可以重新组装。

        Header压缩

        Http2.0开发了专门的“HPACK”算法，大大压缩了Header信息。

        多路复用

        http2.0中引入了多路复用技术，很好的解决了浏览器限制同一个域名下的请求数量的问题。

        服务端推送

        HTTP2.0在一定程度上改不了传统的“请求-应答”工作模式，服务器不再完全被动地响应请求，也可以新建“流”主动向客户端发送消息。

      • http2.0缺陷

        TCP以及TCP+TLS建立连接的延迟（握手延迟）

        TCP的队头阻塞没有彻底解决（http2.0中，多个请求是跑在一个TCP管道中的，一旦丢包，TCP就要等待重传（丢失的包等待重新传输确认），从而阻塞该TCP连接中的所有请求）

    4. http3.0

      • HTTP3.0新特性

        实现了类似TCP的流量控制，传输可靠性的功能。

        实现了快速握手功能（QUIC基于UDP，UDP是面向无连接的，不需要握手和挥手，比TCP快）

        集成了TLS加密功能

        多路复用，彻底解决TCP中队头阻塞的问题（单个“流”是有序的，可能会因为丢包而阻塞，但是其他流不会受到影响

HTTPS

HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。可以理解成HTTPS = HTTP + SSL/TLS。默认端口号是 443。

工作流程

  1. 客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口，类似于 HTTP 的80端口)。
  2. 采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书（证书是需要申请的，并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书 ，当然了是要钱的，安全级别越高价格越贵）。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。
  3. 服务器响应客户端请求，将证书传递给客户端。 证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。（Chrome 浏览器点击地址栏的锁标志再点击证书就可以看到证书详细信息。）
  4. 客户端解析证书并对其进行验证。 如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
    如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。
  5. 客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。
  6. 服务器在收到随机码 KEY 之后会使用私钥B将其解密。 经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。
  7. 服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。

HTTP与HTTPS的区别

HTTP HTTPS
端口 80 443
URL前缀 http:// https://
安全性 无加密，安全性较差 有加密机制，安全性较高
资源消耗 较少 由于加密处理，资源消耗更多
响应速度 快 慢
是否需要证书 不需要 需要
协议 运行在TCP协议之上 运行在SSL协议之上，而SSL运行在TCP协议之上

Cookie和Session和Token

  • Cookie可以存储在浏览器或者本地，Session只能存在服务器
  • session 能够存储任意的 java 对象，cookie 只能存储 String 类型的对象
  • Session比Cookie更具有安全性（Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击）
  • Session占用服务器性能，Session过多，增加服务器压力
  • 单个Cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个Cookie，Session是没有大小限制和服务器的内存大小有关。

JWT

​ JWT 由 3 部分构成:

​ Header :描述 JWT 的元数据。定义了生成签名的算法以及 Token 的类型。

​ Payload（负载）:用来存放实际需要传递的数据

​ Signature（签名）：服务器通过Payload、Header和一个密钥(secret)使用 Header 里面指定的签名算法（默认是 HMAC SHA256）生成。

在基于 Token 进行身份验证的的应用程序中，服务器通过Payload、Header和一个密钥(secret)创建令牌（Token）并将 Token 发送给客户端，客户端将 Token 保存在 Cookie 或者 localStorage 里面，以后客户端发出的所有请求都会携带这个令牌。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP Header 的 Authorization字段中：Authorization: Bearer Token。

DNS

DNS（Domain Names System），域名系统，是互联网一项服务，是进行域名和与之相对应的 IP 地址进行转换的服务器简单来讲，DNS相当于一个翻译官，负责将域名翻译成ip地址

  • DNS查询过程
    1. 首先搜索浏览器的 DNS 缓存，缓存中维护一张域名与 IP 地址的对应表
    2. 若没有命中，则继续搜索操作系统的 DNS 缓存
    3. 若仍然没有命中，则操作系统将域名发送至本地域名服务器，本地域名服务器采用递归查询自己的 DNS 缓存，查找成功则返回结果
    4. 若本地域名服务器的 DNS 缓存没有命中，则本地域名服务器向上级域名服务器进行迭代查询
    5. 本地域名服务器将得到的 IP 地址返回给操作系统，同时自己将 IP 地址缓存起来
    6. 操作系统将 IP 地址返回给浏览器，同时自己也将 IP 地址缓存起
    7. 至此，浏览器就得到了域名对应的 IP 地址，并将 IP 地址缓存起
  • 浏览器输入URL到页面返回详细过程
    1. 输入网址 输入要访问的网址，即URL
    2. 缓存解析 浏览器获取URL后，先去缓存中查找资源，从浏览器缓存-系统缓存-路由器缓存中查看； 如果有就从缓存中显示界面，不再发送请求； 如果没有，则发送http请求；
    3. 域名解析 发现缓存中没有资源，发送http请求； 在发送http请求之前，需要进行DNS解析(域名解析)； DNS解析：域名到IP地址的转换过程，域名的解析工作由DNS服务器完成，解析后可以获取域名相应的IP地址；
    4. tcp连接 三次握手在域名解析后，浏览器向服务器发起了http请求，tcp连接； 因为tcp协议时面向连接的，所以在传输数据前必须建立连接，即三次握手；tcp连接建立后，浏览器开始向服务器发送http请求报文
    5. 收到请求 服务器收到浏览器发送的请求信息，返回响应
    6. 页面渲染 浏览器收到服务器发送的响应，显示页面内容。

OAUTH2

OAuth2.0介绍 OAuth（Open Authorization）是一个关于授权（authorization）的开放网络标准，允许用户授权第三方 应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他 们数据的所有内容。OAuth在全世界得到广泛应用，目前的版本是2.0版。

授权码模式:

一般有四个角色:客户端，服务端，第三方授权服务端，第三方资源服务器

1.当点击QQ登录的时候，客户端会向服务端(一般有个apply_code的接口发起请求)。

2.服务端会向客户端返回一个url,其中url的参数有response_type=code,因为是授权码模式,client_id=appId,就是自己提前已经申请好了的，redirect_uri=url重定向的url,state=state防止csrf攻击

3.客户端收到这个url后会跳转到这个url(访问授权服务器),然后屏幕上就会出现你是否同意登录xxx

4.如果选择了同意,那么客户端会被重定向到url,并且且附带一个授权码和之前传过去的state,然后客户端会将这个传给服务端，服务端通过授权码向认证服务器请求access_token，申请得到access_token后就可以向资源服务器申请用户信息资源。

#网络
计算机网络
http://example.com/2023/09/25/计算机网络/
作者
ykexc
发布于
2023年9月25日
许可协议