必问

Coding求生存
200 阅读13分钟

OSI 的七层模型都有哪些？

应⽤层：⽹络服务与最终⽤⼾的⼀个接⼝。 表⽰层：数据的表⽰、安全、压缩。 会话层：建⽴、管理、终⽌会话。 传输层：定义传输数据的协议端⼝号，以及流控和差错校验。 ⽹络层：进⾏逻辑地址寻址，实现不同⽹络之间的路径选择。 数据链路层：建⽴逻辑连接、进⾏硬件地址寻址、差错校验等功能。 物理层：建⽴、维护、断开物理连接。

HTTP 和 HTTPS

1.http 和 https 的基本概念

http: 是一个客户端和服务器端请求和应答的标准（TCP），用于从 WWW 服务器传输超文本到本地浏览器的超文本传输协议。
https:是以安全为目标的 HTTP 通道，即 HTTP 下 加入 SSL 层进行加密。其作用是：建立一个信息安全通道，来确保数据的传输，确保网站的真实性。

2.http 和 https 的区别及优缺点？

  • http 是超文本传输协议，信息是明文传输，HTTPS 协议要比 http 协议安全，https 是具有安全性的 ssl 加密传输协议，可防止数据在传输过程中被窃取、改变，确保数据的完整性(当然这种安全性并非绝对的，对于更深入的 Web 安全问题，此处暂且不表)。
  • http 协议的默认端口为 80，https 的默认端口为 443。
  • http 的连接很简单，是无状态的。https 握手阶段比较费时，会使页面加载时间延长 50%，增加 10%~20%的耗电。
  • https 缓存不如 http 高效，会增加数据开销。
  • Https 协议需要 ca 证书，费用较高，功能越强大的证书费用越高。
  • SSL 证书需要绑定 IP，不能再同一个 IP 上绑定多个域名，IPV4 资源支持不了这种消耗。

3.https 协议的工作原理

客户端在使用 HTTPS 方式与 Web 服务器通信时有以下几个步骤：

  1. 客户端使用 https url 访问服务器，则要求 web 服务器建立 ssl 链接。
  2. web 服务器接收到客户端的请求之后，会将网站的证书（证书中包含了公钥），传输给客户端。
  3. 客户端和 web 服务器端开始协商 SSL 链接的安全等级，也就是加密等级。
  4. 客户端浏览器通过双方协商一致的安全等级，建立会话密钥，然后通过网站的公钥来加密会话密钥，并传送给网站。
  5. web 服务器通过自己的私钥解密出会话密钥。
  6. web 服务器通过会话密钥加密与客户端之间的通信。 传送门 ☞ # 解读 HTTP1/HTTP2/HTTP3

get 和 post 请求有哪些区别？

  • GET在浏览器回退时是⽆害的，⽽POST会再次提交请求。
  • GET请求会被浏览器主动cache，⽽POST不会，除⾮⼿动设置。
  • GET请求只能进⾏url编码，⽽POST⽀持多种编码⽅式。
  • GET请求参数会被完整保留在浏览器历史记录⾥，⽽POST中的参数不会被保留。
  • GET请求在URL中传送的参数是有⻓度限制的，⽽POST么有。
  • 对参数的数据类型，GET只接受ASCII字符，⽽POST没有限制。
  • GET⽐POST更不安全，因为参数直接暴露在URL上，所以不能⽤来传递敏感信息。
  • GET参数通过URL传递，POST放在Request body中。

TCP三次握手

  1. 第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
  2. 第二次握手：服务器收到syn包并确认客户的SYN（ack=j+1），同时也发送一个自己的SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
  3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。

TCP 四次挥手

  1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
  2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
  3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最 后的数据）。
  4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
  5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
  6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

tcp 为什么要三次握⼿，两次不⾏吗？为什么？

为了实现可靠数据传输， TCP 协议的通信双⽅， 都必须维护⼀个序列号， 以标识发送出去的数据包 中， 哪些是已经被对⽅收到的。 三次握⼿的过程即是通信双⽅相互告知序列号起始值， 并确认对⽅ 已经收到了序列号起始值的必经步骤。 如果只是两次握⼿， ⾄多只有连接发起⽅的起始序列号能被确认， 另⼀⽅选择的序列号则得不到确认。

TCP/IP / 如何保证数据包传输的有序可靠？

对字节流分段并进行编号然后通过 ACK 回复和超时重发这两个机制来保证。 （1）为了保证数据包的可靠传递，发送方必须把已发送的数据包保留在缓冲区；
（2）并为每个已发送的数据包启动一个超时定时器；
（3）如在定时器超时之前收到了对方发来的应答信息（可能是对本包的应答，也可以是对本包后续包的应答），则释放该数据包占用的缓冲区;
（4）否则，重传该数据包，直到收到应答或重传次数超过规定的最大次数为止。
（5）接收方收到数据包后，先进行CRC校验，如果正确则把数据交给上层协议，然后给发送方发送一个累计应答包，表明该数据已收到，如果接收方正好也有数据要发给发送方，应答包也可方在数据包中捎带过去。

TCP和UDP的区别

  1. TCP是面向链接的，而UDP是面向无连接的。
  2. TCP仅支持单播传输，UDP 提供了单播，多播，广播的功能。
  3. TCP的三次握手保证了连接的可靠性; UDP是无连接的、不可靠的一种数据传输协议，首先不可靠性体现在无连接上，通信都不需要建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收。
  4. UDP的头部开销比TCP的更小，数据传输速率更高，实时性更好。 传送门 ☞ # 深度剖析TCP与UDP的区别

HTTP 请求跨域问题

  1. 跨域的原理跨域，是指浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的。
    同源策略,是浏览器对 JavaScript 实施的安全限制，只要协议、域名、端口有任何一个不同，都被当作是不同的域。
    跨域原理，即是通过各种方式，避开浏览器的安全限制。
  2. 解决方案最初做项目的时候，使用的是jsonp，但存在一些问题，使用get请求不安全，携带数据较小，后来也用过iframe，但只有主域相同才行，也是存在些问题，后来通过了解和学习发现使用代理和proxy代理配合起来使用比较方便，就引导后台按这种方式做下服务器配置，在开发中使用proxy，在服务器上使用nginx代理，这样开发过程中彼此都方便，效率也高；现在h5新特性还有 windows.postMessage()
    • JSONP
    • document.domain 基础域名相同 子域名不同
    • window.name 利用在一个浏览器窗口内，载入所有的域名都是共享一个window.name
    • CORS CORS(Cross-origin resource sharing)跨域资源共享 服务器设置对CORS的支持原理：服务器设置Access-Control-Allow-Origin HTTP响应头之后，浏览器将会允许跨域请求
    • proxy代理 目前常用方式,通过服务器设置代理
    • window.postMessage() 利用h5新特性window.postMessage()

跨域传送门 ☞ # 跨域，不可不知的基础概念

Cookie、sessionStorage、localStorage 的区别

相同点：

  • 存储在客户端 不同点：
  • cookie数据大小不能超过4k；sessionStorage和localStorage的存储比cookie大得多，可以达到5M+
  • cookie设置的过期时间之前一直有效；localStorage永久存储，浏览器关闭后数据不丢失除非主动删除数据；sessionStorage数据在当前浏览器窗口关闭后自动删除
  • cookie的数据会自动的传递到服务器；sessionStorage和localStorage数据保存在本地

粘包问题分析与对策

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。
粘包出现原因 简单得说，在流传输中出现，UDP不会出现粘包，因为它有消息边界

粘包情况有两种，一种是粘在一起的包都是完整的数据包，另一种情况是粘在一起的包有不完整的包。

为了避免粘包现象，可采取以下几种措施：
（1）对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满；
（2）对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象；
（3）由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。分包多发。
以上提到的三种措施，都有其不足之处。
（1）第一种编程设置方法虽然可以避免发送方引起的粘包，但它关闭了优化算法，降低了网络发送效率，影响应用程序的性能，一般不建议使用。
（2）第二种方法只能减少出现粘包的可能性，但并不能完全避免粘包，当发送频率较高时，或由于网络突发可能使某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。
（3）第三种方法虽然避免了粘包，但应用程序的效率较低，对实时应用的场合不适合。
一种比较周全的对策是：接收方创建一预处理线程，对接收到的数据包进行预处理，将粘连的包分开。实验证明这种方法是高效可行的。

浏览器

从输入URL到页面加载的全过程

image.png

  1. 首先在浏览器中输入URL

  2. 查找缓存：浏览器先查看浏览器缓存-系统缓存-路由缓存中是否有该地址页面，如果有则显示页面内容。如果没有则进行下一步。

    • 浏览器缓存：浏览器会记录DNS一段时间，因此，只是第一个地方解析DNS请求；
    • 操作系统缓存:如果在浏览器缓存中不包含这个记录，则会使系统调用操作系统， 获取操作系统的记录(保存最近的DNS查询缓存)；
    • 路由器缓存：如果上述两个步骤均不能成功获取DNS记录，继续搜索路由器缓存；
    • ISP缓存：若上述均失败，继续向ISP搜索。

  3. DNS域名解析：浏览器向DNS服务器发起请求，解析该URL中的域名对应的IP地址。DNS服务器是基于UDP的，因此会用到UDP协议。

  4. 建立TCP连接：解析出IP地址后，根据IP地址和默认80端口，和服务器建立TCP连接

  5. 发起HTTP请求：浏览器发起读取文件的HTTP请求，，该请求报文作为TCP三次握手的第三次数据发送给服务器

  6. 服务器响应请求并返回结果：服务器对浏览器请求做出响应，并把对应的html文件发送给浏览器

  7. 关闭TCP连接：通过四次挥手释放TCP连接

  8. 浏览器渲染：客户端（浏览器）解析HTML内容并渲染出来，浏览器接收到数据包后

image.png

avatar
文章
阅读
粉丝