7.9 TCP&HTTP面试题
less than 1 minute read
HTTP
- 常用的HTTP方法有哪些？
- GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器
- POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
- PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
- HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
- DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
- OPTIONS：查询相应URI支持的HTTP方法。
- GET方法与POST方法的区别?
- get重点在从服务器上获取资源，post重点在向服务器发送数据；
- get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用”?”连接; post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的
- Get传输的数据量小，因为受URL长度限制，但效率较高; Post可以传输大量数据，所以上传文件时只能用Post方式
- get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等; post较get安全性较高;
- get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码; post支持标准字符集，可以正确传递中文字符
- HTTP请求报文与响应报文格式?
- 请求报文包含三部分：1). 请求行：包含请求方法、URI、HTTP版本信息, 2). 请求首部字段, 3). 请求内容实体
- 响应报文包含三部分：1). 状态行：包含HTTP版本、状态码、状态码的原因短语, 2). 响应首部字段, 3). 响应内容实体
- 常见的HTTP相应状态码
- 200：请求被正常处理
- 204：请求被受理但没有资源可以返回
- 206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
- 301：永久性重定向
- 302：临时重定向
- 303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
- 304：发送附带条件的请求时，条件不满足时返回，与重定向无关
- 307：临时重定向，与302类似，只是强制要求使用POST方法
- 400：请求报文语法有误，服务器无法识别
- 401：请求需要认证
- 403：请求的对应资源禁止被访问
- 404：服务器无法找到对应资源
- 500：服务器内部错误
- 503：服务器正忙
- 断点续传原理
- HTTP1.1协议（RFC2616）中定义了断点续传相关的HTTP头 Range和Content-Range字段
- 客户端下载一个1024K的文件，已经下载了其中512K , 网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段： Range:bytes=512000-
- 服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加：Content-Range:bytes 512000-/1024000 , 并返回status-code 206
- 文件变化, 如果是根据Last-Modified来标识文件的最后修改时间, 客户端可以If-Match 或者If-Modified-Since 字段帮助服务器判断文件是否变化; 如果是E-TAG, 则客户端可以通过If-Range头
TCP
- TCP和UDP有什么区别？
- TCP是传输控制协议，提供的是面向连接的，可靠地字节流服务。
- TCP是可靠的传输，TCP协议通过确认和重传机制来保证数据传输的可靠性；而UDP是不可靠的传输
- TCP还提供了拥塞控制、滑动窗口等机制来保证传输的质量，而UDP都没有
- TCP是基于字节流的，将数据看做无结构的字节流进行传输，当应用程序交给TCP的数据长度太长，超过MSS时，TCP就会对数据进行分段，因此TCP的数据是无边界的；而UDP是面向报文的，无论应用程序交给UDP层多长的报文，UDP都不会对数据报进行任何拆分等处理，因此UDP保留了应用层数据的边界
- TCP四次挥手过程
- 主机A发送位码为FIN＝1，用来关闭客户A到服务器B的数据传送。此时A的状态为FIN_WAIT_1
- 服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。此时A为FIN_WAIT_2，B为CLOSE_WAIT
- 服务器B关闭与客户端A的连接，发送一个FIN给客户端A。此时A为TIME_WAIT，B为LAST_ACK
- 客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。此时A、B都关闭了，状态变为CLOSED。当（2）、（3）步中的ACK和FIN在一个包中发送时，A的状态会直接从FIN_WAIT_1变为TIME_WAIT
- 为什么建立连接需要三次握手，而断开连接需要四次握手?
- 因为每个方向都需要一个FIN和ACK，当一端发送了FIN包之后，处于半关闭状态，此时仍然可以接收数据包
- 在建立连接时，服务器可以把SYN和ACK放在一个包中发送, 但是在断开连接时，如果一端收到FIN包，但此时仍有数据未发送完，此时就需要先向对端回复FIN包的ACK。等到将剩下的数据都发送完之后，再向对端发送FIN，断开这个方向的连接
- 超时重传和快速重传
- 超时重传：当超时时间到达时，发送方还未收到对端的ACK确认，就重传该数据包
- 快速重传：当后面的序号先到达，如接收方接收到了1、 3、 4，而2没有收到，就会立即向发送方重复发送三次ACK=2的确认请求重传。如果发送方连续收到3个相同序号的ACK，就重传该数据包。而不用等待超时
- accept发生在三次握手的哪一步?
- accept会监听已完成队列是否非空，当队列为空时，accept就会阻塞。当队列非空时，就从已完成队列中取出一项并返回。 而已完成队列中的都是三次握手过程已经完成的，因此accept发生在三次握手之后。
- TCP如何保证传输的可靠性？
- 校验和, 计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。 发送方：在发送数据之前计算检验和，并进行校验和的填充。接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。
- 确认应答和序列号, TCP传输时将每个字节的数据都进行了编号，这就是序列号。 应答即ACK
- 超时重传, 超时重传算法, 按数据重传算法, 如SACK算法
- 连接管理, 三次握手与四次挥手
- 流量控制, TCP滑动窗口
- 拥塞控制, 慢启动, 拥塞避免, 拥塞发生, 快速恢复
- TCP的拥塞控制，具体过程是怎么样的？UDP有拥塞控制吗？如何解决？
参考
