一. 基本概念
1. 概述
- web理念:文档之间相关关联,连成可相互参阅的万维网(www)
- web互连(通讯)的基础:tcp/ip协议族,http属于它内部的子集
- web(www)的三项构建技术:
- html:页面使用什么语言展示
- URL:页面在什么位置
- http:文档之间传递的协议是什么
- tcp/ip协议族分层包括:数据链路层,网络层,传输层 ,应用层
- tcp/ip协议族分层作用:各层各司其职,模块划分清晰,便于维护,解耦
2. 各分层概述
2.1 应用层
- 决定了向用户提供应用服务时通讯的活动
- 包括:FTP,DNS,HTTP等
2.2 传输层
- 提供网络中两台计算机之间的数据传输
- 包括:TCP,UDP
2.3 网络层
- 众多选项中选择合适的传输路径传输数据包
2.4 链路层
- 用来处理网络的硬件部分
3. tcp/ip数据传输方式
- 利用tcp/ip协议族通讯时,通过分层顺序通讯。
- 发送端从应用层往下走,接收端从应用层往上走
- 发送端每经过一层都会被打上该层所属的首部信息,接收端每经过一层将把首部去掉
4. 与http协议密不可分的协议
4.1 IP协议
- 位于网络层
- 作用是把各种数据包传送给对方
- 确保传送正确的两个条件
- IP地址:指明了节点被分配到的地址。可变。
- MAC地址:网卡所属的固定地址。不可变。
4.2 TCP协议
- 位于传输层
- 作用是提供可靠的字节流服务
- 字节流服务:将大块数据分割成以报文段为单位的数据包
- 可靠:采用三次握手策略
4.3 DNS协议
- 应用层协议
- 作用是提供域名到ip地址之间的解析服务
4.4 各种协议的关系
4.5 http协议和tcp协议的区别与联系
区别
- 所属协议层不同:tcp属于传输层,http属于应用层
- 职责不同:tcp解决数据传输问题,http解决数据包装问题
联系
- http协议是构建在tcp协议之上的
- 打个比方:ip是高速公路,tcp是跑在高速公路上的卡车,http是卡车里面的包裹
5. URL与URI
- URL:统一资源定位符,资源的地址。是URI的子集
- URI:统一资源标识符,用字符串标识某一互联网资源
- URI的格式
6. 应用程序划分
- 客户端:请求资源的一端
- 服务端:提供资源响应的一端
- 代理:有转发功能的应用程序,位于客户端和服务器的中间人角色
- 作用:缓存,访问控制
- 网关:转发其他服务器通讯数据的服务器。与代理类似,不过网关能使通信线路上的服务器提供非http协议服务
- 作用:提高安全性:客户端与网关之间的通信线路加密
- 隧道:客户端与服务端建立一条特殊通信线路,使用ssl等手段加密,提高安全性
二. HTTP报文
1. 概述
- 用于http协议交互的信息被称为报文
- 报文分为请求报文和响应报文
- 报文首部字段包括很多维度:内容编码,分块传输,多部分对象集合,范围请求,内容协商等
2. 报文格式
- 报文由报文首部和报文主体两部分组成,中间由空行分开
- 请求行:包含请求方法(get,post),请求URI,http版本
- 状态行:响应结果状态码,原因,http版本
- 首部字段:通用首部,实体首部,请求首部,响应首部
- 其他:cookie等信息
3. 内容编码
- 指明内容等编码格式,客户端负责解码
- 能有效地处理大量等访问请求,不过会消耗更多cpu
- 常用的内容编码
- gzip(GNU zip)
- compress(unix系统标识压缩)
- deflate(zlib)
- identity(不编码)
4. 分块传输
- 把实体主体分块的功能
- 用于传输大容量数据
- 每一块都标记大小,最后一块用0标记
5. 多部分对象集合
- 发送一份报文主体内可包含多类型实体
- 使用时需要在首部字段里添加:Content-type
- 包含的对象如下(content-type的值):
- multipart/form-data:web表单文件上传时使用
- multipart/byteranges:响应报文包含多个范围的内容时使用
6. 范围请求
- 指定范围发送的请求
- 解决网络中断必须从头下载的问题
- 用到首部字段Range指定资源的byte范围:Ranges:bytes=5001-10000
- 响应会返回206状态码和响应报文
7. 内容协商
- 客户端和服务端就响应内容进行交涉,提供最合适的资源
- 协商判断的依据有:响应资源的语言,字符集,编码方式
- 包含的首部字段:Accept,Accept-Charset,Accept-Encoding,Accept-Language,Content-Language
三. 响应状态码
1. 概述
- 描述请求的处理结果
- 状态码的类别
状态码 类别 描述 1XX 信息性状态码 接收的请求正在处理 2XX 成功的状态码 请求正常处理完毕 3XX 重定向状态码 需要进行附加操作以完成请求 4XX 客户端错误状态码 服务器无法处理请求 5XX 服务器错误状态码 服务器处理请求出错
2. 2XX成功
- 200: OK:正常处理
- 204: No Content,服务器接受的请求成功处理,但返回但响应报文不包含主体部分
- 206: Partial Content,服务器成功执行客户端的范围请求,响应报文中包含Content-Range指定范围的内容
3. 3XX重定向
- 301: 永久性重定向,表示请求的资源已经分配了新的uri,以后应使用新的uri
- 302: 临时性重定向,表示请求的资源uri临时性被移动
- 303: 指明客户端应该用Get方法去请求,而不是post
当301, 302, 303状态码返回时,几乎所有浏览器都会把Post改为Get,并删除请求报文的主体,之后请求会自动再次发送
- 304: Get请求中含有附加条件时,请求的资源不满足这些条件。这些附加条件包括:If-Math,If-Modified-Since,If-None-Match,If-Range,If-UnModified-Since中的任意一个
- 307:临时重定向,类似302,不过不会从post变为get
4. 4XX客户端错误
- 400:请求报文中存在语法错误
- 401: 用户认证失败
- 403: 无权限访问
- 404: 无法找到请求的资源,url不存在
5. 5XX服务端错误
- 500: 服务器处理出错,可能是内部的bug
- 502: 错误的网关,资源发送给上游服务器时发送不了
- 503: 服务器处理高负载或停机维护状态,无法处理请求
四. Http首部
1. 首部字段的格式
- 首部字段名:字段值(可为多个)
- 单值:Content-Type: text/html
- 多值:Keep-Alive:timeout=15, max=100
- 首部字段重复,规范里没有明确规定如何处理,各个浏览器不同
2. 首部字段分类
- 通用首部字段:请求和响应都使用的字段
- 请求首部字段:客户端信息,请求的附加信息等
- 响应首部字段:响应的附加信息
- 实体首部字段:请求和响应的实体部分使用的字段
3. 首部字段概览
- http1.1共规定里47中首部字段
3.1 通用首部字段有:
- Cache-Control:控制缓存的行为
- Connection:连接的管理
- Keep-Alive:维持持续连接(http1.1默认持久连接,之前版本没有)
- close:表示关闭持久连接
- 其他首部字段:表示这个首部字段不再转发给代理服务器
- Date:创建时间
- Pragma:报文指令
- http1.0及向前版本的兼容字段
- Trailer:报文末端的首部
- Transfer-Encoding:报文主体传输编码方式
- http1.1仅对分块传输有效
- Upgrade:升级为其他协议
- Via:代理服务器相关信息
- Warning:错误通知
3.2 常用的请求首部字段有:
- Accept:用户代理可处理的媒体类型
- Accept-Charset:优先的字符集
- Accept-Encoding:优先的内容编码
- gizp
- compress
- deflate
- identity
- Accept-Language:优先的语言
- Authorization:web认证信息
- Host:请求资源的服务器
- User-Agent:客户端程序信息
- Range:字段范围请求
- Referer:请求的原始资源的URI
3.3 常用的响应首部字段有:
- Accept-Ranges:是否接受字段范围请求
- Age:推算字段创建经过时间
- Server:服务器的安装信息
- Retry-After:再次发起请求的时机要求
3.4 常用的实体首部字段有:
- Allow:可支持的http方法
- Content-Encoding:实体主体的编码方式
- Content-Language:实体主体的自然语言
- Content-Length:实体主体大小
- Content-Type:实体主体的媒体类型
- Expires:过期时间
- Last-Modified:最后修改时间
3.5 其他首部字段
- Cookie:请求首部字段,服务器收到客户端传来的cookie
- Set-Cookie:响应字段,服务器传给客户端的cookie。包含的属性:
- name=value:cookie的名称和值
- expires:有效期,不指定则默认为浏览器关闭时
- path:服务器上的文件目录作为Cookie的适用对象
- domain:cookie适用对象的域名
- Secure:仅在https安全通信时才会发送cookie
- HttpOnly:Cookie不能被javascript脚本访问
- Connection
- Keep-Alive
五. HTTPS
1. http的缺点
- 通信适用明文(不加密),内容可能会被窃听
- 不验证通信方的身份,可能遭遇伪装。典型如:DOS攻击
- 无法证明报文的完整性,内容可以被篡改。典型如:中间人攻击(MITM)
2. 解决策略
2.1 防止被窃听的对策
- 内容的加密:将http报文所含的内容进行加密。该方案的缺点:
- 需要客户端和服务器都有加密和解密机制
- 内容也有被篡改的风险
- 通信的加密:http协议中没有加密机制,通过和SSL,TLS组合使用,加密http的通信内容。SSL在客户端和服务器建立安全的通信线路。
2.2 防止伪装的对策
- SSL提供的证书,可以作为通讯双方身份认证的功能
2.3 防止内容被篡改的策略
- SSL提供的摘要功能可以解决
3. HTTPS
3.1 概述
- https = http + 加密 + 认证 + 完整性保护
- https并非应用层新协议,只是通信接口部分用SSL和TLS协议代替而已
- http直接和tcp通信。使用ssl时,http先和ssl通信,再由ssl和tcp通信
3.2 常用的加密方式
共享密钥加密
- 也叫对称密钥加密,加密和解密用同一个密钥
- 缺点:无法安全的将密钥发送给接收方
公开密钥加密
- 使用一对非对称的密钥,一把交私有密钥,一把交公开密钥。
- 发送密文的一方使用对方的公开密钥进行加密,对方收到加密信息后用自己的私钥解密
- 不需要发送私钥,不用担心信息被窃取
- 要根据密文和公钥恢复原文信息,以目前的技术是非常困难的
- 缺点:处理速度较慢
3.3 https的加密方式
- 采用共享密钥加密和公开密钥加密两种方式
- 交换密钥环节采用公开密钥加密
- 建立通信之后,报文交换阶段采用共享密钥加密
3.4 数字证书
- 公开密钥加密的问题:无法证明公开密钥本身的正确性
- 解决方案:由数字证书机构和相关机构颁发的公开密钥证书
3.5 为什么不一直使用https
- 加密通信会消耗更多的cpu和内存资源,服务器处理的请求量会降低。所以一般非敏感信息使用http,敏感信息才使用https
- 购买证书的开销比较大
六. http认证
1. 概述
http1.1使用的认证方式有:
- Basic认证
- Digest认证
- SSL客户端认证
- FormBase认证
2. Basic认证
- http1.0就定义的认证方式
- 原理:将”用户名:密码”字符串做base64加密,然后作为首部Authorization字段的值传给服务端
- 缺点:没有加密,安全等级低
- 使用率:并不常用
3. Digest认证
- http1.1定义的认证,为了弥补basic认证的不足
- 原理:发送方请求认证->接收方返回质询码->发送方根据质询码计算响应码发给接收方做验证
- 优点:提供防止密码被窃听的保护机制
- 缺点:无法保证用户被伪装
- 使用率:仍达不到web网站安全要求,使用受限
4. SSL客户端认证
- 借助客户端的证书完成认证
- 双因素认证方式:密码+证书。
- 使用率:客户端证书需要一定费用,尚未普及
5. FormBase认证
- web应用程序各自实现的认证方式
- 使用率:web应用常用的认证方式
6. 状态的管理
- http本身没有状态管理,每次请求并不知道上次请求内容
- 使用Cookie和Session作为状态管理,弥补了http的不足
六. WebSocket协议
1. 概述
- 是html5提供的一种在单个tcp连接上进行全双工通信的协议
2. 为什么会出现该协议?
http协议有以下弊端:
- 一条连接上只可以发送一条请求
- 请求只能从客户端开始,客户端不可用接受除响应以外的指令
- 首部信息没有压缩,延迟大
- 每次请求都要发送冗长的首部信息
- 可任意选择压缩格式,没有强制压缩
websocket协议为解决这些弊端而生。
3. websocket的特点
- 支持服务器向客户端推送数据的功能。服务器可直接发送数据,不用等待客户端请求
- 减少通信量:只要建立连接,就一直保持连接状态。不仅连接开销小,且首部信息很少,减少通信量
4. websocket通信机制
- 在http建立连接后,需要完成一次“握手”步骤
- 附加头信息中添加"Upgrade: WebSocket",表明这是一个申请协议升级的 HTTP 请求
- Sec-WebSocket-Key:记录握手过程中的键值
- Sec-WebSocket-Protocol:记录使用的子协议
作者:kinnylee 链接:https://juejin.im/post/5ba71f7e6fb9a05d37619414 来源:掘金 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。