计网入门还没到放弃

TCP报文段格式

在这里插入图片描述
源端口：标识报文的返回地址
目的端口：指明计算机上的应用程序接口
序号：通过SYN包传给接收端主机，每传送一次就+1，用来解决网络包乱序的问题。
确认号：期望下一次收到的数据的序列号，可以默认这个序号之前的数据都已经收到，防止了丢包的问题。
数据偏移：也称为首部长度，首部长度实际上知识了数据区在报文段中的其实偏移量。
检验和：由发送端填充，在接收端对报文段使用CRC算法以检验TCP报文段是否出现损坏，不仅对TCP头部进行校验，同样也要对数据部分进行校验，这是TCP保证安全性的一个重要保障。

TCP三次握手过程

在这里插入图片描述

第一次握手：客户端 -> 服务端发送SYN报文，包括seq
第二次握手：服务端 -> 客户端发送SYN+ACK报文，包括seq+1,ack，客户端建立连接
第三次握手：客户端 -> 服务端发送ACK报文，包括ack+1，服务端建立连接

为什么必须要三次握手

避免历史连接初始化连接

在网络拥堵的情况下，第一次握手客户端发送的SYN报文，可能服务器宕机没有收到。
在重启客户端的时候，会重新发送SYN报文，同时这个过程会重复很多次，就会有很多历史连接。
那么如果是两次握手，那么服务端在接收到SYN报文的时候，就会建立连接。
但是返回的SYN+ACK报文也会有很多，这时客户端对比了很多的SYN+ACK报文，比如有n个SYN+ACK报文，那么客户端就会发送n-1个RST报文去让进服务端断开连接，只有最后一个是ACK报文。
这样，服务端就会建立很多次链接，浪费资源。
三次握手才可以同步双方的初始化序列号
避免浪费资源

第一次握手丢失的结果

第一次握手丢失，客户端就会一直重发，在重发一定次数之后就会关闭连接。

第二次握手失败的结果

第二次握手丢失，
首先会重发第一次握手，等待一段时间后关闭。
服务端也会一直重发，一定时间内客户端没有收到ACK报文就会断开连接，服务端在重发一定次数后也会断开连接。

第三次握手失败的结果

第三次握手丢失，服务器会重发一定设置次数的ACK+SNY报文，在等待一定时间后，如果没有收到对应的ACK报文，那么就断开连接。ACK报文没有重发机制。

四次挥手

在这里插入图片描述

第一次挥手：客户端 -> 服务端，发送FIN报文，表示想要断开连接，客户端进入FIN_WAIT1状态。
第二次挥手：服务端 -> 客户端，发送ack报文，服务端进入closed_wait状态。
第三次挥手：服务端 -> 客户端，发送FIN报文，客户端接收到ack报文后进入FIN_WAIT2状态，服务端处理完数据后，发送FIN报文，进入LAST_ACK状态。
第四次挥手：客户端 -> 服务端，发送ack报文，客户端接收到FIN报文后进入TIME_WAIT状态，向服务端发送ack报文，服务端接收到ack报文后关闭连接。客户端在经过2MSL时间后关闭连接。

为什么需要四次挥手

第一次挥手，客户端向服务端发送FIN报文，发送FIN报文表示不在发送数据，但是还能接受数据。
第二次挥手，服务端向客户端发送ACK报文，表示同意断开连接。但是可能我还需要发送一些数据。
第三次挥手，服务端发送完数据，向客户端发送FIN报文请求断开连接。
第四次挥手，客户端向服务端发送ACK报文，同意服务端断开连接，服务端接收到ACK报文后，断开连接。

由上述过程可知，服务端需要完成数据的发送会，才会断开连接，所有FIN和ACK一般会分开发送

第一次挥手丢失的结果

会一直重发，一定时间间隔后如果还没有收到第二次挥手就会自动断开连接。

第二次挥手丢失的结果

会一直重发第一次挥手，一段时间后会断开连接。

第三次挥手丢失的结果

如果第三次挥手丢失，如果使用shutdown()关闭连接，那么会一直等待。
如果使用close()关闭连接，那么会等待一段时间后关闭连接。

第四次挥手丢失的结果

会一直重发第三次挥手，一段时间后断开连接。

HTTP协议的特点

HTTP是应用层协议，是基于TCP的可靠协议，是灵活可拓展的，是无状态的。

HTTP报文格式?怎么分割的？

在这里插入图片描述
由请求行、请求头、请求体组成
请求行包括请求方法、URL、HTTP版本号
请求头中包含key-value形式的数据，去说明报文。
请求体中包含需要发送的内容。
他们的分割使用\r\n的方式进行。

HTTP有什么方法？

GET方法：应该只用在查询方法上
POST方法：新增和修改操作
PUT方法：更新操作
DELETE方法：删除操作
HEAD方法：和GET方法类似。

幂等的请求方法，实际上一定幂等吗？

不一定，假如幂等的GET方法，实际上也可以定义一些更新数据的操作，这样就可能不幂等。
要保证幂等，必须按照方法的规定进行才可以。

HTTP状态码

101：请求者要求切换协议
200：成功状态码
204：也表示成功，但是请求体中没有数据。
206：也表示成功，但是请求体中的数据不是全部数据，是断点续传的基础。
301：代表永久性的重定向
303：临时重定向
304：缓存读取
400：请求报文有错误
403：请求资源的权限不够
404：代表服务器上没有该资源
500：服务器程序错误
501：服务器不具有完成请求的功能
502：表示后端服务器发生错误
503：服务器忙
504：请求超时