TCP/IP相关

HTTP


MIME

  • MIME(Multipurpose Internet Mail Extensions): 多用途互联网邮件扩展类型.用途在于设定某种扩展名的文件用一种特殊的应用程序所打开
特地的文件 对应的MIME类型
RTF文本rtf appliation/rtf
普通文本txt txt/plain
gif图形 image/git
au声音文件 audio/basic
avi文件 video/x-msvideo

http协议的特点

  • 灵活: 允许客户端和服务端传输任意类型的对象
  • 无连接: 每次连接只能处理一个请求,处理完客户端请求并结束应答之后立即断开连接
  • 无状态: 对于事务处理无记忆能力,服务器不知道客户端的状态

HTTP中的请求报文

  • 结构分为: 请求行,请求头,空行,请求体

  • 请求行: 中间都由空隔分开 GET /info HTTP/1.1

    • 请求方法: GET POST PUT DELETE
    • URI: /info
    • HTTP协议版本组成
  • 请求头: 由key-value对组成,通过冒号分隔,每行一对

    • 常见的有:
    • User-Agent: 用户代理信息(如书记型号,mac等)
    • Accept: 客户端可以识别的内容类型列表,如 text/htl,application/xhtml+xml ,application/xm
    • Accept-Language: 客户端可以接受的自然语言(中文英文等): zh-CN,zh;q=0.8,en;
    • Accept-Encoding: 客户端可以接受的编码压缩格式: gzipdeflate,sdch,r
    • Host: 请求的主机名(既服务器的域名或者ip)
    • Connection: 连接方式
      • close: 告诉服务器,完成本次连接之后,断开连接
      • keep-alive: 告诉服务器,完成本次请求响应之后,保持连接,等待后续请求
  • 空行,代表不再有请求头

  • 请求体: 只有当请求方法为post的时候才会有数据,其他时候都没有

HTTP的响应报文

  • 结构分为: 状态行,响应头,空行和响应体组成

  • 状态行: **HTTP/1.1 200 ok **

    • 协议版本
    • 状态码
    • 状态码描述符
    • 回车|换行符 组成
  • 响应头: 与请求头类似,常见的有:

    • server: 请求的原始服务器的信息
    • Date: 服务器日期
    • Connectio: 连接方式
      • close: 连接已关闭
      • keep-alive: 连接已保持,在等待本次连接的后续请求
    • Cache-Control: 用于缓存控制
    • Expires: 过期时间,也用于缓存控制
  • 空行: 通知浏览器,不再有响应头

  • 响应体: 既返回的数据

HTTP Methods

  • GET: 用于获取数据,通过url传递参数
  • POST: 通常用于上传数据,通过Request中的请求体
  • PUT: 用于资源更新
  • DELETE: 通常用于删除资源

HTTP的状态码:

  • 1xx: 表示请求已经接受,继续处理
  • 2xx: 成功-表示请求已被成功处理
    • 200: 请求成功
    • 204: No Content: 没有新文档,浏览器可以使用原先的文档
    • 206: Partial Content: 客户端发送了一个带有range 头的get 请求
  • 3xx : 重定向,若要完成请求,必须更进一步的操作
    • 302: 该URL已经过期,使用新的url
    • 304: 提示浏览器可以使用之前的数据
  • 4xx: 客户端错误,请求有语法错误或者请求无法实现
    • 400: Bad Request: 客户端请求有语法错误
    • 401: 未授权,通常与Authentication请求头一起使用
    • 403: 禁止方位: 所请求的资源禁止访问
    • 404: 资源不存在
  • 5xx: 服务端错误
    • 500: 服务器错误
    • 503: 服务器挂了

HTTP的cookie

  • cookie保存在浏览器端
  • Cookie的类别:
    • Session Cookie: 只在会话期内有效,当关闭浏览器的时候,会被浏览器立即删除,
      • 设置方式: 过期时间不设置即可
    • Persistent Cookie: 持久化cookie,长期在用户会话中生效
      • 设置方式: 持久化时间与过期时间相关
    • Secure Cookie: https状态下的cookie,在传输过程中,始终被加密
  • Cookie的用途:
    • 会话管理: 记录用户的登录状态,保存用户的个性化信息
  • Cookie和Session的区别:
    • 每次HTPP请求都会发送相应的Cookie到服务端,实现Session跟踪可以用Cookie实现
    • Session复写的方法:
      • 通过Cookie
      • 通过Uril复写
      • 通过form表单的隐藏域
    • Session是服务端保存的一个数据结构,用来跟踪用户状态,可以存放在其他文件中
    • Cookie是客户端用来保存用户信息的一种机制,使得HTTP状态化

HTTP Cache

  • Http Cache的定义: 是指一个文件在服务器和客户都拿之间的副本,缓存会根据请求的内容保存输出内容到副本中,若下一个请求到来,根据相关请求头和响应头的设置决定 是否直接使用缓存,还是校验是否使用缓存,还是获取到最新的数据
  • Web缓存的类型:
    • 数据库缓存: redis,memcached等
    • 服务端缓存:
      • 代理服务器
      • CDN缓存: 也叫做网关缓存,反向代理缓存
  • 浏览器端缓存:依据请求头和响应头等相关字段,决定
  • WEB应用层缓存: 指的是代码层面

缓存相关的http首部字段

  • 通用首部字段:

    • Cache-Control: 控制缓存的行为,http1.0的一遗留物 当使用no-cache的时候代表禁用缓存
  • 请求首部字段:

    • if-match: 比较etag是否一致
    • if-none-match: 比较etag是否不一致
    • if-Modified-since: 比较资源更新的时间是否一致
    • if-unmodified-since: 比较资源更新的时间是否不一致
  • 响应首部字段:

    • etag: 资源的匹配信息
  • 实体首部字段:

    • expires: http1.0的遗留物,表示实体过期时间
    • Last-Modified: 该资源的最后一次修改时间

缓存方式

  • http1.0 时代,可以使用pragma和expires来规范,至今保留是为了向下兼容,expires过期时间是依据服务器时间而定

  • Cache-Control:

    • 无法保证与客户端时间统一的问题,Http1.1 引入了Cache-Control定义缓存过期时间
    • 注意:
      • Cache-Control: 具体精确到秒
      • 值的形式是通过当前时间的n 秒,而不是具体的时间,这样就解决了expires 服务器和客户端时间不一致的问题
    • 请求首部:
      • no-cache: 表示i代理服务器不直接使用缓存,要求向原服务器发起请求
      • no-store: 所有内容都不会保存到缓存或者其他临时文件中
      • max-age=3 表示在这之后的 3秒内,都能直接使用
      • min-fresh=3 表示客户端希望接受在3秒内更新过的资源
      • no–transform: 告知服务器,客户端希望获取到的数据,不要做任何转换操作
      • only-if-cached: 告知代理服务器,如果有缓存,则把缓存给我,不需要向源服务器发起请求
    • 响应首部:
      • pubic: 表示任何请情况下都缓存资源,即使是https
      • private: 表明除客户端外,数据其他(如代理服务器)不可缓存
      • no-cache: 指不可缓存,每次都需要发起请求
      • no-store: 所有内容都不会保存到缓存中
      • no-transform:缓存时不要对数据进行任何修饰
      • only-if-cached: 告知代理服务求,若客户端自身有缓存,则不需要发起请求
      • must-revalidate: 必须向资源服务器发起验证请求,若请求失败返回504
      • max-age=3s : 告知客户端,该资源在未来3秒内都是最新的,无需发起请求
      • s-max-age: 与max-age一致,不同在于只能使用共享缓存

    缓存校验字段

    • 缓存首部字段能让客户端决定是否需要向服务器发起请求,如过期时间等信息,具体则是如下字段实现的

      • 服务端:

        • Last-Modified: 服务器返回的字段,表示最近一次修改的时间,客户端收到之后会在资源上标记该信息,但客户端发起请求时,会携带
      • 客户端:

        • If-Modifed-Since: 匹配则返回304
        • If-Unmodifed-since: 若服务端Last-Modified没有匹配,则服务端应该返回412同时携带所有的数据返回
      • 服务端:

        • ETAG: 为了解决Last-modifed存在不精确的问题(既ABA,或者1秒内更新多次的问题),HTTP1.1推出了ETAG作为头部字段,客户端会保留ETAG.并在下一次请求时一并带过去
      • 客户端:

        • If-Match: ETag-Vaue 服务器若没有匹配到ETag或者收到了*指,但是没有资源,返回412

          缓存方式 服务端 客户端 缺点
          Expires/Pragma Expires|Pragma Expires Http1.0的产物,时间是相对于服务器而言
          Cache-Control CacheControl Cache-Control 无法向下兼容,
          Last-Modified Last-Modified If-Modified-Since| If-Unmodified-Since 每次请求都会校验,相同304,不同200,无法判断是否真的修改了(ABA问题)
          ETag ETag If-Match | If-None-Match 能够解决ABA问题,以及能够解决一秒内多次修改的为题

    缓存的使用总结

    • 若要兼容HTTP1.0
      • 使用Expires,否则直接使用Cache-Control
    • 若要处理1秒内的多次修改使用ETag,否则使用Last-Modified
    • 对于需要缓存的资源:
      • 服务端: 设定 Expires / Cache-Control + ETag/Last-Modified
      • 客户端: 携带: If-Modified-Since | If-Match
    • 文件标识的采用特殊的形式,如 版本号+md5 ,避免304

HTTP CORS

  • 同源的定义: 指的是protocol,port和host都相同,则两个URL同源,也称为协议主机端口元组

    • 注意: 协议(http1.0 或者 http1.1等)也需要相同
  • 跨域访问:

    • 跨域写: 一般是被允许的
    • 跨域资源嵌入: 也是被允许的
    • 跨域读操作: 则一般不是被允许的
  • 相关的头部字段:

    • access-control-allow-headers 所允许的头部字段
    • access-control-max-age: 表明有效时间内,无需发起预检请求
    • access-control-allow-credentials: 为true表示,浏览器如果没有凭证传过来,则服务器不会响应数据
    • access-control-allow-origin: 所孕育接受的请求的来源
  • 相关的cors字段:

    • Origin: 表示来请求来源于哪站
  • 其他:

    • option是预检请求,检验服务器是否有特殊的要求,如Content-Type,header等信息
  • 注意:

    • 当浏览器ajax withCrentials设置为true时,如果服务器未携带access-control-allow-credentials,则浏览器依旧无法解析到数据

HTTPS

  • 使用对称加密和非对称加密
  • Q: 对所有的客户端都是同一种加密算法吗
    • A: 不是,不同的客户端使用不同的加密算法,采用随机数的方式来统一加密算法
  • Q: 客户端如何获取服务器的公钥
    • A: 客户端向服务器发起请求获取
      • Q: 若中途被掉包怎么办
        • A: 使用数字证书,既不能将服务器端公钥直接传递给客户端,而是第三方机构使用私钥签名之后再发送给客户端,客户端使用第三方机构的公钥验签之后在选择该公钥
      • Q: 若第三方机构是违法中间人怎么办
        • A: 使用数字签名解决第三方机构合法性问题
      • Q: 第三方机构如何合法性校验
        • A: 客户端本地验证
          • Q: 为什么不采用远程验证
            • A: 因为又多了一次交互
          • Q: 本地如何验证:
            • A: 浏览器和OS,自己维护一个权威的第三方机构列表

TCP 中的首部格式:

  • 固定20字节
    • 第一部分:
      • 源目端口 (各16bit)
      • 序号:32bit
        • TCP连接中传输的字节流中每一个字节都按顺序编号,首部中的序号既报文段中发送的数据的第一个字节序号
      • 确认号:32bit
        • 4个字节,是期望收到的对方下一个报文的序号
    • 2
      • 数据偏移量: 4bit
      • 保留位: 6bit
      • URG
      • ACK
        • 当ACK=1的时候,确认号(ack)有效,反之无效,建立连接之后,所有发送的报文段都必须把ack置1
      • PSH
      • RS
      • SYN
        • 当SYN=1,ACK=0,表明这是一个连接请求的报文
      • FIN
        • 当FIN=1时,表明次报文的数据发送已经完毕,请求断开连接
      • 窗口:16bit
    • 3
      • 校验和: 16位
      • 紧急指针:16位
    • 4
      • 选项(长度可变)
      • padding 填充

TCP的三次握手

  • 客户端创建TCB,发起连接请求报文段,SYN=1,表示连接请求,client处于SYN-SENT状态
  • 当服务器收到请求后,发起一个SYN=1,ACK=1的连接接受报文段(不能携带数据,但是依旧会消耗一个序号)server处于SYN-RECVD状态
  • 当客户端收到接受报文后,需要发送回应一个请求,此时ACK=1(能携带数据,如果不携带数据则不会消耗序列号) 过了一会双方处于ESTABLISHED状态

TCP的四次挥手:

数据传输完毕之后,双方都可以释放连接,最开始的时候,客户端和服务器都处于ESTABLISHED状态,通常由client端主动关闭

  • client申请连接释放,发出确认报文,ACK=1,ack=u+1,seq=v,v=已经接受到的字节+1,server会通知高层的应用进程;cliient处于FIN-WAIT-1状态
  • server端收到client的连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的seq=v,server通知高层应用进程,关闭客户端的server端方向(因为tcp是全双工的),server处于CLOSE-WAIT状态
  • client收到server的确认包,client处于FIN-WAIT-2状态,等待server发送连接释放报文(Q:为什么需要再等待一次server的链接释放报文)
  • 此时的server依然在传输数据,传输完之后,FIN=1,ack=u+1,seq=w,server进入LAST-ACK状态
  • client收到server的连接释放报文,发出确认包,ACK=1,ack=u+1,seq=u+1,client进入TIME-WAIT状态,此时tcp连接依旧没有释放,会经过2*MSL时间后,client销毁TCB才进入close状态
  • server收到ACK包,进入 closed状态,同样销毁TCB之后,结束本次连接

  • Q: MTU的作用

  • Q: TCP握手为什么不是2次或者4次

    • 2次的情况:
      • 既当server返回ACK报文之后,client不回送一个ACK报文,则若发生网络延误问题,既A1请求建立连接报文在网络中阻塞,client 触发超时重传,重新发送A2,之后业务执行完毕断开连接之后,A1网络畅通,到达server端,2次握手使得直接建立连接,因而也就导致了连接资源的浪费,3次的话,client发现业务已经完毕了的,所以不会回传ACK报文
    • 4次:用现实场景最合理
      • clienet: 喂,听的到吗
      • server: 嗯,听得到,听得到我吗
      • client: 嗯,听得到
  • Q: TCP为什么认为是可靠的,是通过什么实现的

    • 确认和重传机制: 建立连接时需要三次握手同步,双方的序列号+确认号+窗口大小信息是确认重传流控的基础,并且checksum校验
    • 数据排序,tcp有专门的序列号sn字段,提供数据的重排序
    • 流量控制: 滑动窗口和计时器的作用,tcp窗口指明双方能够发送的数据包的最大值
    • 拥塞控制:由4个核心算法组成
      • 慢启动:
      • 拥塞避免
      • 快速重传
      • 快速恢复
  • Q: 4次挥手,为什么建立连接要3次,而挥手多了1次

    • 多的一次在于,server发送一次ACK确认释放报文
    • 因为建立连接的时候,是没有数据报文传输的,而挥手的时候,双方依旧能够传输数据,多的挥手在于告诉对方,数据彻底传输完毕:
  • Q: client为什么要的呢古代2*MSL才进入close_wait状态

    • A:
      • client角度: 确保最后一个ACK报文能到server,因为可能ACK报文会丢失
      • server角度: 当server发送了FIN+ACK报文,客户端还没有回应,应该是请求没有到达client,所以会触发超时重传,而客户端就能在2msl时间内收到这个重传的报文,接着给出回应报文,并且刷新2msl计时器
      • 同时与三次握手为什么不是二次一样,防止失效的连接请求报文段出现在本连接中,client发送完最后一个确认包后,2*msl时间内报文段都将在网络中丢失
  • Q: 若建立连接之后,但是client故障怎么办

    • A: TCP有一个保活计时器,既当客户释放请求的时候,server不会一直等待,server每次收到client的一次请求,都会重新复位(通常为2h),2h未收到任何数据,就会发送一个探测报文,间隔一段时间达到一定次数,就会认为client故障,从而关闭连接
  • Q: 四次挥手中,server和client的状态变更

    • client: FIN-WAIT-1 => FIN-WAIT-2 => TIME-WAIT => CLOSED
    • server: CLOSE-WAIT => LAST-ACK => CLOSED

疑问

  • 204状态码,No Content的具体作用

  • cache-control 中

    • no-cache和 max-age=0 的区别
    • 以及no-cache 禁用缓存,是否会真的禁用缓存?
  • Q: 什么是实体首部字段

    • A: 既资源的字段
  • Q: pragma,cache-control,expires的优先级

  • Q: no-cache和no-store的区别

  • Q: 资源A ,如何强制从服务器获取最新的资源:

    • Cache-Controle:max-age=0 +If-Modified-Since 强制请求浏览器判断是否过期,
      • 是则返回304,缓存中的数据是最新的数据
      • 否: 返回200 ,不是从缓存中获取数据
  • Q: 为什么要避免304,以及如何避免304

    • A: 304 代表着需要向服务器发起请求,避免304也就避免了请求,减少IO 网络通信
    • 如何避免304:
      • 既使得浏览器从缓存中获取值,既状态码为 200 (from cache)
        • 服务端返回的时候,设定Cache-Control + Last-Modified: 并且时间设置合理,使得获取资源的时候发现本地资源并没有过期,直接从缓存中拿
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值