HTTP网络相关--akakdlfhahfuquiruqoirhjhkjhk

islandsaying
289 阅读19分钟

  1. http请求与响应/状态码/缓存/版本1.0,1.1,2.0,3.0

    1. http请求与响应
      • 报文内容/结构
        1. 请求
          • 请求行：（请求方法/资源位置/HTTP版本协议）GET /09-1 HTTP/1.1
          • 请求头： 使用key-value形式更详细的说明报文
          • 请求体： 实际传输的数据，文本或者图片视频的二进制数据
        2. 响应
          • 响应行：（HTTP协议版本/状态码/原因）HTTP/1.1 200 OK
          • 响应头： 使用key-value形式更详细的说明报文
          • 响应体： 响应返回的数据等信息
      • 常见请求头和响应头（常用头分为通用字段/请求字段/响应字段/实体字段）
        1. Accept： 浏览器能够理解的内容类型
        2. Acctept-sharset： 浏览器能够支持的字符集
        3. Acctept-Encoding： 浏览器能够理解的压缩编码
        4. Accept-langulage： 浏览器当前设置的语言
        5. connection：浏览器和服务区之间链接状态控制
          • connection：keep-alive： 省去每次链接都需要进行的TCP三次握手， 直接进行一次三次握手就能形成会话，然后在这一次三次握手中进行多次http请求。
        6. Cookie：当前页面设置的任何cookie
        7. Host：请求将要发送的服务器主机名和端口
        8. Referer： 请求页面请求的来源地址
        9. User-Agent： 一个特征字符串， 用以识别发起请求的用户代理软件的应用类型，操作系统软件开发商（Mozilla/5.0（xnn。Linux-86-64. Applewekit/... chrome/51.xxx））
        10. Date：表示报文创建的时间， 客户端可以使用这个世界再搭配其他字段决定缓存策略
        11. Server： 当前正在提供web服务的名称和版本号
        12. Connection： 见上
        13. Cache-control：控制http缓存
        14. Content-type： 表示后面的文件类型
          • mutipart/form-data： 表单上传文件
          • application/json： 序列化后的JSON字符串
          • text/xml： xml格式
    2. 请求方式
      1. 常用
        • get 获取数据，请求上幂等的（多次操作结果相同为幂等）
        • post 发送提交数据，请求非幂等
        • delete 删除数据时使用
        • put 更新数据的时候时使用，需要传输全部字段
        • patch -更新部分数据的时候使用，不需要传递全部字段
      2. 不常用
        • options 获取服务器允许使用的方法
        • head 只获取头部，但不获取数据
        • connect 使用很少 为建立特殊连接渠道
      3. 一些区别（以get和post为例）
        • get参数放在url中， 因为url长度被浏览器限制，故其请求参数有大小限制，而post则没有限制
        • get请求只接受ascii码，post无此限制
        • get相对于post较不安全，因为参数放在url中，请求会被浏览器所记录
    3. http状态码
      1. 1xx 表示请求已被接受但需要后续处理
        • 100 continue 客户端应继续发送请求
        • 101 switch protocols 需要切换协议
      2. 2xx 请求已成功被服务器接收，理解并接受
        • 200 ok 请求已成功， 响应头和数据随之返回
        • 201 created 请求已被实现，新资源已创建（post）
        • 202 accept 服务器已接受请求，但尚未处理，如post应该资源应当返回201， 但由于性能原因未能立即上传创建，可以返回202
        • 204 no content 服务器已经成功处理了请求，但不需要返回任何实体内容
      3. 3xx 重定向 这类代码需要客户端采取进一步操作才能完成请求，重定向的目标在本次响应的location字段
        • 301 move permanently 永久重定向 请求的资源已永久移到新位置，浏览器会要求用户确认重定向
        • 302 found 临时重定向
        • 303 see other 重定向指向其他页面而非资源页面， 如消息确认/上传进度页面
        • 304 not modified 内容未改变， 是一种浏览器缓存机制
          1. （需要发送请求）ETag/If-none-match/If-match： 文件内容缓存
          2. （需求发送请求）Last-modified/If-modified-since 文件修改时间缓存
          3. （可避免请求）Expires/Cache-control
      4. 4xx 客户端响应
        • 400 bad request 语义有误，无法被服务器理解/请求参数有误
        • 401 unauthorized 需要用户的授权信息（未验证）
        • 403 forbidden 服务器理解了请求，但拒绝执行
        • 404 not found 请求的资源未在服务器上发现
        • 405 method not allowed 请求方法不能被用于相应资源
        • 413 request entyty too large 请求提交的数据超限
        • 414 request url too large 请求url太长
      5. 5xx 服务器在处理请求的过程中有错误或者异常状态
        • 500 internal server error 通常是代码出错，后台bug
        • 502 bad gateway 该服务器作为网关需要得到一个处理这个请求的响应，但得到一个错误响应
        • 504 gateway time-out 响应超时（通常是被墙了）
    4. http缓存
      • 流程图
      • 总结:
        1. 先看看是否命中强缓存,如果命中就直接使用缓存了
        2. 如果没有命中强缓存, 就发请求到服务器检查是否命中协商缓存.
        3. 如果命中协商缓存,服务器就会返回304告诉浏览器使用本地缓存.
        4. 否则返回最新的资源.
      • 强缓存: 通过本地缓存支援的header判断
        1. Expires(headr中)
          • 例子: Expires: Fri.27 OCT.2017 07:55:30 GMT(使用GMT时间格式)
          • 缺点: 是绝对时间, 如果修改了客户端本地时间,则会使其失效
        2. Cache-control(也放在header中)
          • 例子: Cache-control: Max-age=300(既然不能使用绝对时间,那就用相对时间)
          • 一些字段:
            1. no-cache: 不是不缓存,而是可缓存,但在使用前需要使用Etag/last-modified进行校验
            2. no-store: 禁止使用缓存, 每一次都要重新请求数据
            3. pubilc: 默认值,中间环节和客户段都可以进行缓存
            4. privaite: 只能客户端进行缓存,中间的一切步骤如路由器,运营商都不能
      • 协商缓存: 在强缓存没有命中的时候, 浏览器会发送一个请求到服务器, 服务器根据请求头中的部分信息来判断是否命中缓存, 如果命中则返回304,告诉浏览器资源未更新, 可使用本地的缓存
        1. Last-modified(资源第一次被请求而返回的header上带的最后修改时间)
          • 例子: last-modified: Fri.27 OCT 2017 07:55:30 GMT (绝对时间)
          • 说明: 浏览器再次请求该资源时, 用请求头中字段if-modified-since与当前的last-modified(第一次返回的last-modified值)对比,如果没有过期则返回304
          • 缺点: 最小单位是秒(再小就无法知道);资源周期性还原,其实可以使用缓存, 但last-modified不这么认为
        2. Etag(由文件内容hash生成,保证资源的唯一性)
          • 例子: Etag: w/e-cbxLfqw52qGcq
          • 说明: 浏览器第一次请求资源时,服务器会返回Etag标识, 当再次请求该资源时,通过请求中的if-none-match与服务器中的Etga值进行比对,如果相等则返回304
        3. 两个协商缓存可同时设置,服务器会优先校验Etag,再对比last-modified最后决定是否返回304.
    5. http版本
      1. http1.0(默认使用短链接)
        • http协议的第一个版本, 存在诸多问题, 很快被1.1取代
        • 缺点:
          1. 每次发送http请求都需要进行tcp连接(三次握手四次挥手), 造成链接冗余
          2. 第二个请求只有在第一个请求受到回应后才能发出, 容易造成数据阻塞
      2. http1.1(为解决1.0版本问题而生, 但依旧存在问题)
        • 解决的问题:
          1. 默认采用长链接方式, 添加字段connection:keep-alive, 一次握手后可以进行多次链接。 2. 改进流水线作业的方式,后续请求不需要等待前面的请求响应才发出, 可直接发出且顺序不变.
          2. 引入了更多的缓存策略,如Etag, if-match等
        • 存在的问题:
          1. 每个域名下只能同时发送6个请求, 超出的请求在前面回应到来之前处于pending状态
          2. 只能客户端发送,不能服务器发送
          3. 每次请求的请求头数据类似,信息冗余, 且没有进行压缩
          4. 请求顺序无优先级, 只能按照html请求的顺序
      3. http2.0(为解决1.1版本问题而生, 并且进行了诸多优化)
        1. 二进制传输: http2.0优化的核心在此,之前的http版本中, 数据通过文本的形式传输, 现在是将所有的数据进行分割,采用二进制编码传输
        2. 多路复用:
          • http2.0中的重要概念就是帧和流.
          • 帧是代表最小的数据单位, 每个帧会标识出该帧属于哪个流, 流也就是多个帧组成的数据流.
          • 多路复用就是在一个TCP连接中可以存在多条流, 换句话说就是可以发送多个请求,对端可以通过帧的标识知道属于哪个请求,通过这个技术,可以避免队头阻塞问题,极大提高传输性能.
        3. header压缩
          • 在http/1版本中,我们使用文本的形式传输header, 在header携带cookie的情况下, 可能每次都要重复传输几百到几千的字节
          • 在http/2中, 使用了hpack压缩格式对传说的header进行编码压缩以此减少header大小.
          • 并且在两端维护了一个索引表, 用以记录出现过的header, 这样再传的时候可以直接传键名, 对端通过键名找到键值.
        4. 服务端push: 服务端在收到客户端的某个请求后会主动push相关联的资源
      4. http3.0(针对tcp的丢包问题, 引出了一个基于udp的quic协议, 新增了一些功能, 如多路复用, 0-rtt, 使用tls1.3加密, 流量控制, 有序交付, 重传等 0. 丢包以亲的问题是需要等待重传, 导致后面所有的数据都被阻塞了
        1. 多路复用: tcp是基于ip和端口去识别连接的,在多变的移动端网络环境下比较脆弱. 但quic是通过id的方式去识别一个连接, 不管网络环境如何变化, id不变就能迅速连上
        2. 0-rtt: 缓存当前会话的上下文, 在下次恢复会话的时候, 只需要将之前的缓存传递给服务端验证通过就可以进行传输了
        3. 纠错机制:
          • 假设这次要发送三个包, 那么协议会算出这三个包的异或值并单独发出一个校验包, 也就是总共发出了四个包.
          • 当出现其中的非校验包丢包的情况时, 可以通过另外三个包计算出丢失的数据报的内容.
          • 当然这种技术仅限于丢失一个包, 如果是多个包则需要重传
      5. 小结:
        • http/2 通过多路复用, 二进制流, header压缩等技术, 极大的提高了性能,但还是存在问题的
        • quic基于udp实现, 是http/3中的底层支撑协议, 该协议基于udp, 又取了tcp中的精华, 实现了即块又可靠的协议.

  2. https

    1. https
      • 概念：超文本传输安全协议，HTTPS经由HTTP进行通信，利用SSL/TLS来加密数据包。HTTPS的主要目的是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
      • SSL/TLS的全称安全传输层协议（Transport Layer Security），其功能实现只要依赖三类基本算法：散列函数hash，对称加密，非对称加密。其中：
        1. 散列函数验证信息的完整性
        2. 对称加密算法采用协商的密钥对数据加密，对称加密就是两边拥有相同的密钥，两边都知道如何将密文加密解密。这种加密方式固然很好，但是问题就在于如何让双方知道密钥。因为传输数据都是走的网络，如果将密钥通过网络的方式传递的话，一旦密钥被截获就没有加密的意义的。
        3. 非对称加密实现身份认证和密钥协商，有公钥私钥之分，公钥所有人都可以知道，可以将数据用公钥加密，但是将数据解密必须使用私钥解密，私钥只有分发公钥的一方才知道。这种加密方式就可以完美解决对称加密存在的问题。假设现在两端需要使用对称加密，那么在这之前，可以先使用非对称加密交换密钥。简单流程如下:首先服务端将公钥公布出去，那么客户端也就知道公钥了。接下来客户端创建一个密钥，然后通过公钥加密并发送给服务端，服务端接收到密文以后通过私钥解密出正确的密钥，这时候两端就都知道密钥是什么。
        4. 通过数字证书和CA认证来确定公钥是安全正确的。
    2. https的通信过程
      1. 客户端向服务器发起请求，请求中包含协议版本号，一个随机数，以及客户端支持的加密方法。
      2. 服务端收到请求后，确认双方使用的加密方法，并给出服务器的证书，以及一个服务器生成的随机数。
      3. 客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥加密这个随机数，然后发给服务器。并且还会提供一个前面所有内容的hash值，用来供服务器进行校验。
      4. 服务器使用自己的私钥，来解密客户端发送过来的随机数。并根据前面提供的hash值进行校验。
      5. 客户端和服务器端根据约定的加密方法使用前面三个随机数，生成对话密钥，以后的对话过程都使用这个密钥来加密和解密信息。
    3. https的优缺点
      1. HTTPS的优点如下：
        • 使用HTTPS协议可以认证用户和服务器，确保数据发送到正确的客户端和服务器；
        • 使用HTTPS协议可以进行加密传输、身份认证，通信更加安全，防止数据在传输过程中被窃取、修改，确保数据安全性；
        • HTTPS是现行架构下最安全的解决方案，虽然不是绝对的安全，但是大幅增加了中间人攻击的成本；
      2. HTTPS的缺点如下：
        • HTTPS需要做服务器和客户端双方的加密个解密处理，耗费更多服务器资源，过程复杂；
        • HTTPS协议握手阶段比较费时，增加页面的加载时间；
        • SSL证书是收费的，功能越强大的证书费用越高；
        • HTTPS连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本；
        • SSL证书需要绑定IP，不能再同一个IP上绑定多个域名

  3. TCP/UDP

    • 概念: UDP(User datagram protocol 用户数据包协议), TCP(Transfer control protocol传输控制协议)
    • 相同点: 都是传输层协议, 都属于tcp/ip协议族
    • 不同点: (从UDP视角)
      1. 面向无连接:
        • 首先UDP不需要和TCP一样在发送数据前进行三次握手建立连接, 想发数据就可以发送了
        • 并且也只是数据报文的搬运工, 不会对数据报文进行任何拆分和拼接操作, 具体就行
          1. 在发送端, 应用层将数据传递给传输层的UDP协议, UDP只会给数据增加一个UDP头标识下是UDP协议, 然后就传递给网络层了(数据+UDP头标识)
          2. 在接收端, 网络层将数据传递给传输层, UDP只去除IP报文头就传递给应用层, 不会任何拼接操作
      2. 不可靠性:
        • 首先不可靠性体现在无连接上, 通信都不需要建立连接, 想发就发, 这样的情况肯定不可靠
        • 并且收到什么数据就传递什么数据, 也不会备份数据, 发送数据也不会关心对方是否已经正确收到数据了.
        • 再者网络环境时好时坏,但是UDP因为没有拥塞控制, 一直会以恒定的速度发送数据. 即使网络条件不好, 也不会对发送速率进行调整.其弊端就是在网络条件不好的情况下可能会导致丢包, 但是优点也很明显,在某些实时性要求高的场景(比如电话会议)就需要使用UDP而不是TCP
      3. 高效:
        • 虽然不是那么可靠, 但是正因为不是那么可靠所以也没有TCP那么复杂
        • 因此UDP的头部开销小, 只有八字节, 相比于TCP的至少二十字节要小的多, 所以在传输数据报文时是很高效的.
        • UDP头部包括 端口号/数据报文/数据报文的校验字段
      4. 传输方式
        • UDP不止支持一对一的传输方式, 同样支持一对多, 多对多, 多对一的方式, 也就是说UCP提供了单播, 多播, 广播的功能.
    • 不同点(以TCP视角)
      1. 面向连接: 发送前必须在两端建立连接(三次握手)
      2. 可靠传输:
        • 编序号防丢包,会重传,按序传输
        • 拥塞控制: 网络出现拥塞的时候, 减小数据传输的速率和数量, 缓解拥塞
      3. 传输方式
        • 仅单播传输: 点对点, 一对一, 不支持广播, 多播
      4. 适用场景:
        • TCP适合效率要求相对低,准确性要求相对高的场景,如文件传输, 邮件, 远程登录
        • UDP适合效率要求相对高,准确性要求相对低的场景,如QQ聊天, 在线视频, 语音电话, 广播等
    • TCP的三次握手/四次挥手
      1. 三次握手
        • 概念: 三次是保证client和server均让对方知道自己接收和发送能力没问题而保证的最小次数
        • 过程:
          1. 第一次: client => server 只能server判断出client具备发送能力
          2. 第二次: server => client, client可以判断出server具备发送, 接收, client还需让server知道自己接收能力ok
          3. 第三次 client => server, 双方均保证了自己的接收和发送
          4. 另外, 为了保证后续握手是为了应答上一次握手, 每一次握手都会带标识seq, 后续ack都会对这个seq进行加1来确认
        • 图
      2. 四次挥手
        • 概念: TCP断开连接的方式, 双方都可以主动断开连接, 断开后主机中的资源将会被释放
        • 过程:
          1. 第一次: 客户端打算关闭, 发信息给server, client => server(Fin)
          2. 第二次: server收到关闭信息后向client回答确认(ack), 准备关闭(等会就自行关了)
          3. 第三次: 服务端server处理完数据,向client发送Fin报文(关闭确认), server=>client Fin
          4. 第四次: client收到Fin后 回server一个ack, client=>server ack, server关闭
          5. 至此: server关闭, client随后关闭

  4. DNS

    • 概念：domain name system 域名管理系统
    • 背景：因ip长且难记，访问不便，于是发明了DNS服务。当我们输入网站域名， DNS服务器将我们的域名解析为ip， 这样我们实际访问的就是对应的ip地址
    • 例子：当用户中浏览器中输入ke.qq.com并检索后，本机内部会
      1. 查找浏览器缓存，如果有则直接结束解析过程
      2. 查找系统缓存，如果有则直接结束解析过程
      3. 路由器缓存
      4. ISP（Internet Server Provider 互联网服务提供商）DNS缓存
      5. 从根服务器递归查询

  5. CDN

  6. 从输入URL到页面展示发生了什么?

    1. 网络的请求和响应
      • 网络请求:
        1. 构建请求
        2. 查找强缓存, 如果命中则直接使用, 否则进入下一步
        3. DNS(域名系统)解析, DNS的作用就是通过域名查询到具体的IP,(以www.google.com)为例
          1. 操作系统会首先在本地缓存中查询IP
          2. 没有的话去系统配置的DNS服务器中查询
        4. 建立TCP连接
          1. 会经历TCP的三次握手来建议客户端与服务器之间的连接
          2. 进行数据传输
          3. 数据传输完成后会断开链接, 通过四次挥手
        5. 发送http请求, TCP连接建立完毕后, 浏览器和服务器开始通信,即开始发送http请求
          • 请求行, 请求头和请求体
          • 请求头中的一些标识信息如缓存相关
      • 网络响应
        • http请求到达服务器, 服务器进行对应的处理, 然后返回网络响应
          • 响应行, 响应头和响应体
          • 响应完成后,tcp连接是否断开取决于请求头/响应头中的connection字段, 如果是keep-alive,表示建立了持久连接, 这样tcp会一直保持,之后请求统一站点的资源会复用这个连接. 否则断开tcp连接, 请求-响应流程结束.
    2. 浏览器的解析与渲染
      • 浏览器开始解析文件, 如果是gzip会先解压一下,然后通过文件的编码格式知道该如何去解码文件
      • 根据HTML构建Dom树, 有CSS的话会去构建CSSDOM树,如果遇到script标签的话, 会判断是否存在async或者defer, 前者会并行进行下载并执行js, 后者会先下载js文件然后等到html解析完成后顺序执行, 如果以上都没有,就会阻塞住渲染流程知道js执行完毕.
      • Dom树和Cssom树构建完成之后会开始生成布局树(layout tree),这一步就是确定页面元素的布局, 样式等等诸多方面的东西
      • 在生成布局树(layout tree)的过程中, 浏览器就开始调用GPU绘制, 合成图层, 将内容显示在屏幕上了
avatar
文章
阅读
粉丝