HCIA复习（TCP和静态路由）

抽象语言（文字、语音、图片）----->电脑可以识别的机器语言
抽象语言---->编码
编码------->二进制数
二进制数---->电信号

OSI/RM七层参考模型 

分层----核心思想

应用层---->人机交互的接口
表示层---->将编码转换为二进制，其本质是将格式进行统一。
会话层---->搭建一个端到端的连接。
传输层---->区分不同点的应用。端口号
网络层---->IP地址(IP协议)--->逻辑寻址
数据链路层---->MAC地址（以太网协议）--->物理寻址
物理层---->物理特性（端口数量大小、电气电压标准）

ARP协议----地址解析协议

• 正向ARP：根据已知的目标IP地址获取目标MAC地址
  • ARP缓存表—>通过ARP协议获取到的信息为动态信息。180S
• 反向ARP：根据已知的目标MAC地址获取目标IP地址
• 免费ARP：1.自我介绍；2.地址的冲突检测；一般是在DHCP获取到IP地址后使用。

交换机的工作原理

 

    交换机转发原理：交换机收到电信号后，会将电信号转换为二进制，之后，截取数据帧。
                1、首先查看数据帧中的源MAC地址，之后将该地址和数据进入接口的对应关系记录在本地的MAC地址表中。--->300S
                2、查看数据帧中的目的MAC地址，基于本地MAC地址表进行查找，如果表中存在对应记录关系，则执行单播转发；如果表中不存在对应关系，则进行洪泛（交换机会将数据从除了进入的接口外的所有接口发送一遍）

    

交换机洪泛的情况

1、收到广播帧或组播帧的情况下，会进行数据洪泛

2、收到未知单播帧

 

DNS服务—域名解析服务

​ 基于UDP/TCP 53号端口进行封装。一般在客户端和服务端之间的查询和响应使用UDP协议；TCP协议用于主备服务器之间的数据传输。

DNS的查询过程----递归查询、迭代查询

 路由器的转发原理：路由器基于数据包中的目的IP地址，查询本地路由表。若表中存在对应路由信息，则无条件转发数据；若表中不存在，则丢弃该数据包。

TCP----传输控制协议

是一种面向连接的可靠传输协议。可靠、有序、无丢失和无重复

特点：

TCP是一种面向连接的传输协议
每一条TCP连接有且只能存在两个端点，形成一种端到端的连接形式。
可靠、有序、无丢失和无重复
TCP是提供全双工通讯。
     发送缓存
          想要发送的应用层数据
          已经发送但未收到确认的数据
     接收缓存
          按需到达但还未被应用程序提取的数据
          乱序到达的数据
TCP是面向字节流的。

 TCP----传输控制协议

是一种面向连接的可靠传输协议。可靠、有序、无丢失和无重复

特点：

——TCP是一种面向连接的传输协议
——每一条TCP连接有且只能存在两个端点，形成一种端到端的连接形式。
——可靠、有序、无丢失和无重复
——TCP是提供全双工通讯。
-发送缓存
         想要发送的应用层数据
         已经发送但未收到确认的数据
-接收缓存
         按需到达但还未被应用程序提取的数据
         乱序到达的数据
——TCP是面向字节流的。

 

源IP、源端口、目IP、目端口----->TCP会话的四元组信息。

套接字：IP：Port
 

TCP报文段

 

确认序列号表明是接收方期望收到发送方发送的下一个字节的序号；且表示之前的所有数据均已接收。–>累积确认。 

ACK确认位：当ACK=1时，确认序列号有意义。在连接建立后所有传输的报文段都必须将该标记位置为1。
SYN同步位：代表连接请求。
FIN终止位：表明此报文段发送方数据已发送完毕，要求释放连接。

RST复位：当TCP连接出现严重错误时，必须释放连接，然后重新建立传输连接。
URG紧急位：当URG=1时，表明此报文段中存在紧急数据，是高优先级数据，应尽快传输给应用层程序处理，不再缓存在排队。配合紧急指针使用。
PSH推送位：当PSH=1时，接收方应尽快交付数据给应用层程序，不再等待缓存填满再向上交付。
 

 

 

 TCP的可靠性

排队机制

确认机制和重传机制

超时重传--快速重传

在快速重传机制中，并不是因为RTO时间到达从而触发重传机制，该重传机制是根据对端的反馈信息进行重传，当连续3三收到相同的ACK报文时，发送端会重传数据。这3个连续的ACK报文被称为冗余ACK。  

累积确认---选择确认

选择确认机制也是需要进行协商的 

 窗口--窗口：指定的是无需等待确认应答，而可以继续发送数据包的最大值。

TCP面向连接

TCP连接的建立

 TCP连接建立需要解决的问题：
1、要使双方均知晓对方的套接字信息。
2、允许双方进行参数协商（MSS、窗口值、是否使用选择确认机制）
3、给各设备进行资源分配

TCP连接的释放

1、对双方各自资源的释放过程
2、任何一方都可以在数据传输结束后发送连接释放通知

 

 三次握手

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

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。
进行三次握手：

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。此时客户端处于 SYN_SENT 状态。

首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

 

 

发送第一个SYN的一端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）。

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

 

 

 

1.1 为什么需要三次握手，两次不行吗？

弄清这个问题，我们需要先弄明白三次握手的目的是什么，能不能只用两次握手来达到同样的目的。 

• 第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，需要三次握手才能确认双方的接收与发送能力是否正常。

试想如果是用两次握手，则会出现下面这种情况

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

 

 

 四次挥手

建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。 

TCP 连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，客户端或服务端均可主动发起挥手动作。

刚开始双方都处于ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

• 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。

即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。

• 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。

• 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。

• 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。

在socket编程中，任何一方执行close()操作即可产生挥手操作