Http/Https详解和TCP
复杂网络环境
host主机 A—数据丢包—数据重复—数据完整性校验—数字转换模拟信息–。。。。—信号衰减—host主机 B
网络分层
网络通信在不同方面是有层次结构的,每一层仅于他上一层或者下一层进行交互,只要层与层之间接口不变就不会影响其他层
**OSI七层模型:**应用层,表示层,会话层,传输层,网络层,数据链路层,物理层。
TCP/IP 5层模型:应用层、传输层、网络层、数据链路层、物理层
传输层协议:TCP、UDP、SCTP
网络层协议:ipv4、v6,ARP、ICMP
数据链路层协议:以太网、无线LAN
HTTP协议
无状态以请求和应答方式运行的协议,使用可扩展语义和自描述消息格式
**无状态:**指不存储用户信息
**可扩展语义:**使用头部字段定义所需要信息
**自描述消息格式:**数据可以是文本图片音频等
1、http报文格式
http报文格式=起始行+头部字段集合+空行+消息正文
**起始行:**描述请求或响应的基本信息,GET /inedex.html HTTP/1.1或者HTTP/1.1 200 ok,header.
**头部字段集合:**使用键值对形式详细说明报文,connection:keep-alive
**消息正文:**实际传输数据可以是任何满足条件数据,
1.1、请求报文格式
格式=method+空格+url+空格+version+换行符
请求方法method:
get/post/head/put/delete
请求目标URL:
URL标记请求资源位置
版本号version:
http协议版本(1.0之后有,1.1后标准化)
1.2、响应报文格式
格式=version+空格+statusCode+空格+reason+换行符
版本号version
表示http协议版本
状态码StatusCode
一个三位数,用代码表示服务器处理结果
-
1**,服务器收到请求,需要请求者继续执行操作 100继续,101服务器根据客户端请求切换请求的协议如请求切换http1.1 -
2**,成功,操作被成功接收并处理
200 200ok请求get和post常见 | 204 无内容,服务器处理成功但是没有返回内容,浏览器会先确保当前显示页面 |
---|
201 已创建请求所需资源 | 205 充值内容,服务器处理成功,重置用户视图 | 202 接收请求但没有完成处理 | 206 只有部分内容被处理,且是get请求 | 203 非授权信息请求成功,但返回的meta信息不在原始服务器,是副本处理的 | |
-
3**,重定向,需要进一步操作完成请求
300 多种选择,请求资源来自多个位置需要用户在返回的列表选择 | 304 未修改。所请求资源没有修改,此状态下服务器不返回任何东西 |
---|
**301 **永久移动,请求资源被永久移动到新url,返回信息包括新uri浏览器也会自动定向到新url | 305 使用代理,所求资源需要代理才能访问 | 302 临时移动,301类似,但是资源只是临时移动,所以C端先继续使用当前url | 306 | 303 查看了其他地址。使用get和post请求查看 | 307 临时重定向状态参考307 |
-
4**,客户端错误,请求包含语法错误或无法完成请求
400 服务器无法理解,客户端请求语法错误 | 405 客户端请求中方法禁止 |
---|
401 请求要求用户的身份验证 | 406 服务器无法根据内容特性完成请求 | 402 保留 | 407 与401类似,但是要使用代理服务器进行授权 | 403 服务器理解客户端请求,但是拒绝执行 | 408 超时,服务器等待客户发送请求时间超时 | 404 服务器无法更具C端请求找到资源 | 409 服务器完成客户端put请求,但是发生了冲突 | 411 服务器无法处理客户端发送的不带content-length的请求信息 | 410 客户端请求资源不存在 |
-
5**,服务端错误,但是处理过程中发生了错误
500 服务器内部错误 | 503 服务器超载或系统维护,暂时无法处理客户端请求 |
---|
501 服务器不支持该请求 | 504 充当网关或代理服务器没有及时获取该请求 | 502 代理服务器收到一个无效请求 | 505 服务器不支持C端http协议的当前版本postman简介 |
原因Reason
作为数字状态码进行补充,更加详细的解释文字
2、 http头字段header
以键值对形式存在,用CRLF表示字段结束。如果是前后端分离项目,经常需要content-type:application/json,来让后端处理json数据。
由于http的可扩展性,所以我们处理标准的host或者connection等已经存在的header同时,支持添加其他自定义头
响应头 | 说明 |
---|
allow | 服务器支持哪些请求方法 | content-encoding | 文档编码方法,只有编码后才可以得到content-type头指定文件 | content-length | 表示内容长度,当浏览器使用持久http连接才需要这个数据 | content-type | 表示文档属于什么mime类型,servlet默认text/plain,但通常是text/html。httpservletresponse提供一个专用方法setcontenttype(跟开发有关) | date | 设置gmt时间,用setdateheader来设置这个头以避免转换时间格式麻烦(返回服务器相对于当地的时间记得时区+8) | expires | 决定文档在什么时候过期,而不再进行缓存 | www-authenticate | 客户应该在authorization头中提供什么类型的授权信息,包含401状体行的应答中这个头是必须的 | last-modified | 文档最后改动时间,客户通过if-modified-scine请求头提供一个日期,该请求头会被视为一个条件get,只有改动时间迟于指定时间文档才能返回,否则是304状态 | location | 表示用户去哪里提取文档,location不是直接设置的通常使用httpservletresponse的sendRedirect方法,状态码302 | refresh | 表示浏览器应在多少时间后去刷新文档,秒记,指的是n秒后刷新本页面或访问指定页面 | server | 服务器名字,web服务器自己定义 | set-cookies | 设置和页面关联的cookies |
header数据内部顺序不影响语义
3、http请求完整过程
HTTPS协议
针对网络传输的安全性,向http协议内加入ssl/tsl安全套接层对http协议的请求和响应报文进行加密
1、对称加密和非对称加密
对称加密
使用相同加解密密钥,高效适用于大量数据加密场景,算法公开,安全性取决于密钥大小,但密钥越大效率越低
非对称加密
生成一对匹配的密钥分别进行加密和解密,两个公钥一个私钥(先有私钥,然后根据私钥生成公钥)
公钥加密
针对加密数据发送
私钥签名
将明文公布给别人,同时证明该明文是自己发的。
- A将明文和通过该明文在A私钥下生成的hash值(密文签名发送给B)
- B通过A的公钥A的hash值,然后跟A发送过来的密文签名做对比,判断是否A发送信息
2、https请求前SSL/TSL完整过程
- 首先有一个CA权威机构专门存储各个服务器的CA证书,各个客户都自带CA机构的公钥
- 每个服务器的CA证书都是用该服务器本身的公钥A和域名依照CA机构私钥生成的,
- 浏览器请求某个服务器访问,会先去CA机构下载该服务器的证书,通过CA机构公钥解密出该服务器的域名和公钥
- 以上三步后,浏览器会自己生成浏览器的对称加密密钥,然后依照CA证书解密后的访问服务器的公钥将浏览器的对称加密密钥生成一个密文,通过域名发给服务器。
- 服务器获取到该密文和通过自己的服务器私钥进行解密,获取到浏览器的对称加密密钥,然后通知发送密文浏览器我已经接收到对称加密密钥
执行完上述加密步骤后,浏览器才会请求数据响应报文,建立TCP链接(参照)
TCP协议
特点
- 基于连接使用的双向数据传递(全双工),因为到达目的地的数据路径是不固定的
- 不限制数据大小,数据打包成报文段保证有序接收,重复报文自动丢弃。会自己校对是否丢包,丢包后客户端会要求服务器重发
- 保证数据可到达,丢包时通过重发机制保证发送的可靠性
- 可以有效防止网络出现恶性拥堵
基于tcp连接四元组:目的地址、目的端口、源地址、源端口
实际连接时五元组,除以上四要素外还要考虑协议头
1、TCP如何看到应用交付数据
tcp协议将应用传递的数据仅仅当成一连串的无结构字节流,tcp不会理解字节流的含义也不会考虑应用程序会将多大数据加入到tcp的缓存中,tcp只会根据对端(连接的远端)给出的窗口(涉及替代重发机制的滑动窗口协议)和当前网络状况来决定一个报文应该包含多少字节。
总结,TCP协议只是打工人,只决定一次发送多少数据。
2、tcp报文组成
Sourece port(源端口,客户端随机生成) | Dest port(目的端口) |
---|
Sequence number | | Acknowledgment number | | headerlength(报文长度),unused/cwr/ECE/URG/ACK/PSH/RST/SYN/FIN(报文标识) | Receive Window(当前服务器可接收数据大小) | Internet checksum() | Urgent data pointer(紧急数据处理指针) | options(可选参数) | | data(放置http协议数据) | |
3、tcp三次握手建立连接
- 客户端进入SYN-Sent状态,向服务器发送SYN,seq=x报文,此时服务器接收报文,进入监听状态,存储当次报文内信息(目的端口、目的ip、序号、应答号等信息)
- 服务端接收信息后会发送ACK报文和SYN seq=Y(对客户端发送的SYN seq=X的响应报文)报文,告诉客户端连接建立信息收到预计建立连接,客户端进入Established状态
- 客户端在收到服务端确认报文后,向服务端再次发送ACK报文接收确认报文(ACK ack=y+1),此时服务端接收后同时进入established状态,两端建立连接
服务端状态
4、tcp四次挥手断开连接
- 客户端发送FIN类型TCP数据包,代表客户端不在发送数据
- 服务端收到请求,开始应答(ACK),避免客户端重新发送FIN数据包(ACK 包告诉客户端)
- 服务端处理完数据后关闭连接,像客户端发送FIN请求包
- 客户端收到服务端FIN包后像服务端发送ACK进行二次确认
- 客户端等待2msl后在释放连接,防止报文丢失和重发以及新连接造成数据扰乱
挥手等待时间长是为了防止客户端由于丢包等原因没有获取到服务端发来的ACK的TCP报文,留出空余时间等待重发。
还有就是防止造成新建立连接时的缓慢,因为正常断开连接是要关闭端口的,若是断开时有服务端其他进程也要使用该端口建立连接,而断开该端口连接的进程还没有执行完毕,则会造成进程冲突,这就会导致新连接建立缓慢。
5、TCP滑动窗口协议和累计确认
比延时重发重传更加有效的机制
假设tcp一个窗口有五个报文,中间3报文丢失,最后对端校验发现3报文数据丢失,则对端要求下一次发送窗口时应当包含丢失的报文
|