TCP HTTPS专题

TCP HTTPS专题

TCP协议

TCP/IP协议分层

TCP/IP 协议族里重要的一点就是分层。 TCP/IP 协议族按层次分别分为以下 4 层： 应用层、 传输层、 网络层和数据链路层。
把 TCP/IP 层次化是有好处的。 比如， 如果互联网只由一个协议统筹， 某个地方需要改变设计时， 就必须把所有部分整体替换掉。 而分层之后只需把变动的层替换掉即可。 把各层之间的接口部分规划好之后， 每个层次内部的设计就能够自由改动了。值得一提的是， 层次化之后， 设计也变得相对简单了。 处于应用层上的应用可以只考虑分派给自己的任务， 而不需要弄清对方在地球上哪个地方、 对方的传输路线是怎样的、 是否能确保传输送达等问题。

TCP/IP 协议族各层的作用如下。

应用层
应用层决定了向用户提供应用服务时通信的活动。
TCP/IP 协议族内预存了各类通用的应用服务。 比如， FTP（ File Transfer Protocol， 文件传输协议） 和 DNS（ Domain Name System， 域名系统） 服务就是其中两类。HTTP 协议也处于该层。

传输层
传输层对上层应用层， 提供处于网络连接中的两台计算机之间的数据传输。在传输层有两个性质不同的协议： TCP（ Transmission ControlProtocol， 传输控制协议） 和 UDP（ User Data Protocol， 用户数据报协议） 。

网络层（ 又名网络互连层）
网络层用来处理在网络上流动的数据包。 数据包是网络传输的最小数据单位。 该层规定了通过怎样的路径（ 所谓的传输路线） 到达对方计算机， 并把数据包传送给对方。与对方计算机之间通过多台计算机或网络设备进行传输时， 网络层所起的作用就是在众多的选项内选择一条传输路线。

链路层（ 又名数据链路层， 网络接口层）
用来处理连接网络的硬件部分。 包括控制操作系统、 硬件的设备驱动、 NIC（ Network Interface Card， 网络适配器， 即网卡） ， 及光纤等物理可见部分（ 还包括连接器等一切传输媒介） 。 硬件上的范畴均在链路层的作用范围之内。

TCP三次握手

用三次握手建立TCP连接

用三次握手建立TCP连接

顺序解释：

1. Client发送同步SYN报文，序号seq为x，Client进入SYN-SENT状态
2. Server接收到Client的SYN报文，发送SYN、ACK报文，序号seq为y，确认号ack为Client的SYN报文的seq+1（x+1），Server进入SYN-RECVD状态
3. Client接收都Server的SYN、ACK报文，发送ACK报文，序号seq为（x+1），确认号ack为（y+1），Client进入ESTABLISHED状态
4. Server接收到Client的ACK报文，进入到ESTABLISHED状态

为什么是三次握手：
三次握手是为了解决网络延迟大的情况会发生的数据错误问题。

假设不使用三次握手：
Client->Server (发送同步信息)
Server->Client (确认同步信息)
Server处于等待的状态
Client由于延迟的原因已经丢失了链接，Server会一直等待Client的数据，会有资源的消耗

采用了三次握手
Client->Server (发送同步信息)
Server->Client (确认同步信息)
Server处于等待的状态
Client由于延迟的原因已经丢失了链接，Server没有收到Client的确认信息，会断开连接

来自知乎的答案：

作者：郭无心
链接：https://www.zhihu.com/question/24853633/answer/63668444
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
TCP连接建立过程中为什么需要“三次握手”在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不用的表述其实阐明的是同一个问题。谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
这个例子很清晰的阐释了“三次握手”对于建立可靠连接的意义。
在Google Groups的TopLanguage中看到一帖讨论TCP“三次握手”觉得很有意思。贴主提出“TCP建立连接为什么是三次握手？”的问题，在众多回复中，有一条回复写道：“这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.”。这可视为对“三次握手”目的的另一种解答思路。
后面一段话意思就是如果想确定双通道通畅，必须使用三个包的发送接收，也就是三次握手
http://www.cr173.com/exam/Cisco_17954_1.html

TCP四次挥手断开连接

TCP四次挥手断开连接

顺序解释：

1. Client发送连接释放的报文，停止再发送数据，自动关闭TCP连接，发送FIN报文，序号seq为传送过的数据的最后一个字节的序号加1（假设为u），Client进入FIN-WAIT-1状态
2. Server接收到Client的FIN报文，发送确认ACK报文，确认号ack为Client的FIN报文的序号seq加1（u+1），Server端进入CLOSE-WAIT状态，Client端接收到ACK报文进入FIN-WAIT-2状态，这时TCP处于半关闭的状态，Client到Server方向的通道不能发送数据了，Server到Client方向的通道如果有数据还能继续发送，Client也能接收到
3. Server没有数据再发送了，发送FIN、ACK包，确认号ack为Client的FIN报文的序号seq加1（u+1），序号seq假设为w，Server进入LAST-ACK状态
4. Client接收到Server的FIN报文，发送FIN报文，序号seq为上一个报文的的seq加1（TCP规定发送FIN报文需要消耗一个序号），确认号ack为Server的序号值w加1（w+1），Client进入TIME-WAIT状态需要等待两倍的MSL(maximum segment lifetime 最长报文段寿命) 才会进入CLOSE状态
5. 服务器接收到ACK报文进入CLOSE状态

TCP状态变迁图

状态变迁图

包含了三次握手和四次挥手的状态变换，红色序号代表了三次握手的顺序，蓝色序号代表了四次挥手的的顺序
黑色粗实线表示的是客户端的状态变化，黑色粗虚线表示的是服务端的状态变化，黑色细实现表示的是非正常状态的变化

HTTPS

HTTPS 的通信步骤:

HTTPS 的通信步骤

步骤 1： 客户端通过发送 Client Hello 报文开始 SSL通信。 报文中包含客户端支持的 SSL的指定版本、 加密组件（ Cipher Suite） 列表（ 所使用的加密算法及密钥长度等） 。

步骤 2： 服务器可进行 SSL通信时， 会以 Server Hello 报文作为应答。 和客户端一样， 在报文中包含 SSL版本以及加密组件。 服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

步骤 3： 之后服务器发送 Certificate 报文。 报文中包含公开密钥证书。

步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端， 最初阶段的 SSL握手协商部分结束。

步骤 5： SSL第一次握手结束之后， 客户端以 Client Key Exchange 报文作为回应。 报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。 该报文已用步骤 3 中的公开密钥进行加密。

步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。 该报文会提示服务器， 在此报文之后的通信会采用 Pre-master secret 密钥加密。

步骤 7： 客户端发送 Finished 报文。 该报文包含连接至今全部报文的整体校验值。 这次握手协商是否能够成功， 要以服务器是否能够正确解密该报文作为判定标准。

步骤 8： 服务器同样发送 Change Cipher Spec 报文。

步骤 9： 服务器同样发送 Finished 报文。

步骤 10： 服务器和客户端的 Finished 报文交换完毕之后， SSL连接就算建立完成。 当然， 通信会受到 SSL的保护。 从此处开始进行应用层协议的通信， 即发送 HTTP 请求。

步骤 11： 应用层协议通信， 即发送 HTTP 响应。

步骤 12： 最后由客户端断开连接。 断开连接时， 发送 close_notify 报文。 上图做了一些省略， 这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。

在以上流程中， 应用层发送数据时会附加一种叫做 MAC（ MessageAuthentication Code） 的报文摘要。 MAC 能够查知报文是否遭到篡改， 从而保护报文的完整性。