yrl's blog
0%

TCP HTTP HTTPS

发表于 更新于 分类于

TCP

TCP-建立连接（三次握手）

  • client端发送一个SYN包告诉server端自己的初始序列号是X，进入SYN_SENT状态

  • server端收到SYN，返回客户端ACK（X+1）和自己的SYN seq=Y，进入SYN_RCVD状态

  • client端收到后回复server端ACK（Y+1），此时双方进入ESTABLISHED（TCP连接成功）状态，完成三次握手

    请求-确认-建立连接

问题

为什么需要三次握手才能建立连接呢？

1
2
3
4
5
第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可。

为什么要传送ACK呢？

1
为确保是同一个客户端的请求，建立可靠的TCP连接

为什么TCP客户端最后还要发送一次确认呢？

​ 如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

​ 如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接

TCP-释放连接（四次挥手）

  • client端发送FIN包告诉server端即将断开连接，client端进入FIN-WAIT-1（终止等待1）状态
  • server端收到后回复client端ACK，此时server端进入CLOSE-WAIT（关闭等待）状态，客户端收到服务器的确认请求后，此时client端就进入FIN-WAIT-2（终止等待2）状态
  • server端没有数据需要发送时，发送FIN包给client端，server端进入了LAST-ACK（最后确认）状态
  • client端收到后回复server端ACK，此时client端进入了TIME-WAIT（时间等待）状态，server端收到ACK进入CLOSED状态，注意此时client端的TCP连接还没有释放，必须经过2*MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态

客户端请求断开-服务端确认

服务端请求断开-客户端确认

问题

为什么客户端最后还要等待2MSL？

​ MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

​ 第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

​ 第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

​ 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
​ 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

参考

HTTP

1
2
3
4
HTTP是建立TCP协议的。
TCP是OSI七层协议中的第四层传输层协议，定义的是数据传输和连接方式的规范。
HTTP是第七层的应用层协议，定义的是传输数据的内容的规范。
HTTP协议中的数据是利用TCP协议传输的。

HTTPS

HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。

  • 第一步：客户端告诉服务端其所能支持的加密算法 + 客户端生成的随机数client-random

  • 第二步

    • 服务端从客户端传送的加密算法中选取一种，并返回告诉客户端
    • 服务端随机数server-random
    • 证书（密文 + 签名 + 签名算法 ） => CA的私钥（server.公钥） = 密文；算法hash（server.公钥） = 签名

  • 第三步

    • 客户端使用CA的公钥解密得到server.公钥，并根据协商好的算法对该公钥计算后与签名比对，成功则证明请求没有被伪造；
    • 使用server.公钥对新生成的随机数premaster-random进行加密

  • 第四步

    • 服务端使用server.私钥对客户端传送的密文进行解密，得到permaster-random，将三个随机数通过一定算法生成对称加密的key；
    • 之后的http传输协议中，双方使用此key进行对称加密

为什么使用CA机构签发的证书？

如果不使用CA机构签发的证书，单纯由服务端使用私钥签发公钥；那么中间代理商可能获取服务端发出的公钥，再自己伪造私钥签发假公钥转发给客户端；客户端获取代理商分发的假公钥进行加密，被代理商截取之后使用自己的私钥解密，窥探到数据；代理商再替代客户端向服务端发送虚假数据。

如果使用CA进行加签，当客户端使用公有的CA公钥对证书进行解密时，因为代理商无法拿到CA的私钥，只能使用CA公钥加密的数据，而CA公钥加密的数据在客户端无法使用CA公钥正确解密；所以当客户端使用得到的server.公钥，根据约定的加密算法计算的值与签名不对应，则证明请求被伪造。

合法的CA机构会和操作系统打交道，将CA公钥内置在操作系统中，浏览器获得证书后通过CA.公钥进行解密证书获得Server.公钥，这个步骤代理服务器没有CA.私钥，它没办法伪造一个不合格的证书。