HTTP 和 HTTPS

HTTP

是什么

超文本传输协议

三次握手

建立一个 TCP 连接时，客户端和服务端一共需要发送 3 个包。三次握手的主要作用是确认双方 的发送能力和接收能力是否正常、指定自己的初始化序列号为后面的可靠性传输做准备。实质上 就是连接服务器指定的端口号，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。

1、三次握手过程

一开始的时候，client 处于 closed 状态；server 处于 listen 状态。

进行三次握手：

• 第一次：客户端给服务端发一个 SYN 报文，同时指明客户端的 ISN，此时客户端处于 SYN_SENT 状态。
• 第二次：服务端收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并指定自己的 ISN。 同时把客户端的 ISN + 1 作为 ACK 值，表示自己已收到客户端的 SYN，此时服务端处于 SYN_RCVD 状态。
• 第三次：客户端收到 SYN 报文之后，会发送一个 ACK 报文(服务端 SYN + 1)，表示已经收到 服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。当服务端收到 ACK 报文后也处于 ESTABLISHED 状态，此时双方已建立连接。

socket 编程中，客户端执行 socket() 时，将触发三次握手。

2、为什么需要三次握手，两次可以么？

2.1、三次握手的目的：

• 第一次：服务端收到客户端的报文后确认客户端的发送能力正常；
• 第二次：客户端收到服务端的报文后确认服务端的接收能力、发送能力正常；
• 第三次：服务端收到客户端的报文后确认客户端的接收能力正常；

2.2、两次握手有什么问题？

防止已失效的连接请求报文突然又传输到了服务端从而产生错误

1
2
3

客户端发起两次连接，但是第一次因为网络阻塞没有收到，只收到了第二次；第二次建立连接并完
成通讯后，双方都关闭了连接；此时第一次请求到底服务端了，服务端随即建立连接，客户端忽略
服务端发来的确认，也不发送数据，服务端一直等待客户端发送数据，造成服务端资源浪费。

3、半连接队列

4、ISN(Initial Sequence Number)是固定的么？

5、三次握手过程中可以携带数据么？

6、SYN 攻击是什么？

四次挥手

• 第一次：客户端发送 FIN 报文并在报文中指定 seq 号，此时客户端处于 FIN_WAIT1 状态；
• 第二次：服务端收到 FIN 并回应 ACK 报文，且把客户端的 seq + 1 作为 ACK 报文的 seq， 表明已接收到服务端报文，此时服务端处于 CLOSE_WAIT 状态；
• 第三次：如果服务端也想断开连接，则和客户端第一次挥手一致，发送 FIN 报文并指定 seq， 此时服务端处于 LAST_ACK 状态，等待客户端确认；
• 第四次：客户端收到 FIN 后，一样发送一个 ACK 作为应答，且把服务端的 seq + 1 作为自己 的 ACK 报文的序列号，此时客户端处于 TIME_WAIT 状态，需要过一阵子以确保服务端收到自己 的 ACK 报文之后才进入 CLOSED 状态

特点

• 无状态：协议对客户端没有状态存储，对事务处理没有记忆能力，比如网站需要反复登录
• 无连接：HTTP/1.1 之前，由于无状态，每次请求都需要 TCP 三次握手
  • cookie/session
  • Connection: keep-alive，只要任意一端没有明确提出断开连接，则保持 TCP 连接
• 基于请求和响应：client 请求、server 响应
• 简单快速、灵活
• 明文请求、响应；不安全；无法保证数据的完整性

HTTPS

是什么

超文本安全传输协议，基于 HTTP，通过 SSL/TLS 提供加密数据处理、验证对方身份以及数据完整保护

实现原理

• 协议、默认端口号
• 明文传输、加密传输、安全
• 效率

特点

• 内容加密
• 验证身份
• 保护数据完整性

HTTPS 如何校验证书合法？

关键词：数字签名、消息摘要、根证书、证书链 原因：防止中间人攻击

1、服务端将证书通过 hash 算法生成消息摘要； 2、使用私钥将消息摘要加密生成数字签名； 3、服务端通过 CA 证书的公钥验证证书签名；

B 站笔记

0 输入 1 输出 2 错误

打开 TCP 连接并重定向到 fd 9 中

exec 9<> /dev/tcp/www.baidu.com/80

进入该进程 fd 目录

cd /proc/$$/fd

通过 socket 发送 HTTP 请求

echo -e “GET / HTTP/1.0\n” 1>& 9

读取 HTTP 响应

cat 0<& 9

为什么 TCP 是面向连接的可靠的传输协议？

面向连接：通过三次握手建立 TCP 连接

可靠：数据包序列号是在握手过程中确定的

client->server: SYN=1, seq=x

server->client: SYN=1,ACK=1,seq=y,ack=x+1

client->server: ACK=1,seq=x+1,ack=y+1

为什么是三次握手？

确认双方的通信能力和可靠性

TCP 断开四次挥手

socket 套接字：四元组 [{ip+port} + {ip+port}]

port：65536 个，及时释放、资源耗尽

FIN

ACK

FIN

ACK

为什么四次？

tcpdump 抓包

tcpdump -nn -i eth0 port 8080

HTTP 与 HTTPS

HTTP：明文传输、中间人攻击

HTTPS=HTTP + SSL/TLS

1、内容加密：混合加密，无法获取明文；

2、验证身份：证书认证客户端访问的是自己的服务器；

3、保护数据完整性：中间人攻击

HTTPS

SSL -> TLS(实现 X509 协议)

OpenSSL 是 TLS 的一种开源实现，用来生成证书

证书颁发者 -> 证书(网站) -> 访问者

可信任的第三方：CA，权威机构

证书：一对公钥和私钥，包含颁发机构、过期时间、服务端公钥；证书可以自己制作也可以向组织申请，自制证书需要客户端验证通过才可继续访问，使用受信任的公司申请的证书不需要通过客户端校验

颁发者将证书颁发给网站，网站的访问者从网站拿到证书

对称加密：加密解密使用相同的密码，效率高

密码需要通过网络传输，如何不通过网络传输密码？如何保证密码不外泄？

离线加密狗：U 盾密码在硬件中，需要插入电脑才能使用

非对称加密：加密解密使用不同的密码，效率低

私钥加密公钥解密；公钥加密私钥解密

OpenSSL 先生成私钥，再通过私钥生成公钥；

TCP 三次握手之后 SSL 第四次握手：

1、client 发送随机值和支持的加密算法给 server；

2、server 响应随机值和匹配好的加密算法；

3、server 响应数字证书(公钥)给 client；

4、client 解析证书，由 TLS 来完成：首先验证公钥是否有效（颁发机构、过期时间）；若证书异常则弹出警告提示证书有问题，若证书正常，则生成随机值作为预主密钥；

5、client 认证证书通过后，接下来通过随机值1、随机值2和预主密钥组装会话密钥，然后使用证书的公钥及加密会话密钥；

6、传送 #5 加密的信息；

7、server 解密得到随机值1、随机值2和预主密钥，然后组装会话密钥（与 client 一致）；

8、client 通过会话密钥加密一条消息发送给 server，用于验证 server 是否正常接受 client 加密的消息；

9、同样 server 也会通过会话密钥加密一条消息发送给 client，若 client 能够正常接收则表示 SSL 层建立成功；

如何保证 server 下发给 client 的公钥是真正的公钥，而不是中间人伪造的公钥？

证书如何安全传输？