TCP与HTTP-面试题

最新推荐文章于 2024-10-06 21:32:58 发布

你可真逗了

最新推荐文章于 2024-10-06 21:32:58 发布

阅读量1.2k

点赞数

分类专栏： java面试题

本文链接：https://blog.csdn.net/han451375136/article/details/105600860

版权

java面试题专栏收录该内容

6 篇文章 0 订阅

订阅专栏

TCP与HTTP面试题

http1.0和http1.1有什么区别。

http基于tcp/ip协议，创建tcp链接需要经过三次握手后才能获取资源，如果每次请求都要这样创建对性能会有影响,此时就需要长连接来保持，减少创建成本。http1.0需要使用keep-alive参数主动告知服务器创建长连接，儿http1.1默认支持长连接：Connctiong:keep-alive
http1.1 增加了host域：http1.0认为每台服务器都绑定一个唯一的ip地址，因此请求消息url中并没有传递主机名。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且他们共享一个ip地址，http1.1请求中如果没有host头域会报告错误：400 Bad Request
http1.1可以只发送header信息,服务端正常返回100，异常401.接收到100状态时，客户端可以继续发送body体，这样可以节约宽带，减少无效请求，其也是文件断点续传的基础。
http1.1 增加24个错误状态响应码。如：409 表示请求的资源与该资源当前的状态冲突。410 表示服务器上资源被删除。

TCP三次握手和四次挥手的流程，为什么断开连接要4次,如果握手只有两次，会出现什么。

三次握手：
- 第一次握手：客户端发送连接请求到服务器，此时客户端进入同步已发送状态(SYN-SEND)
- 第二次握手：服务器收到连接请求报文，并向客户端发送确认，服务端进入同步收到状态(SYN-RCVD)
- 第三次握手：客户端收到服务端的确认，再次向服务端给出确认。此时服务端可客户端都进入已建立连接状态(ESTABLISHED)
如果握手只有两次:如果缺少第三次握手，服务端不接收客户端的再次确认信息，容易导致客户端和服务端状态不一致。如：客户端发送的请求由于某种原因延迟发送的服务端，客户端在超时情况下重试发送请求，忽略延迟请求。当该延迟请求到达服务端后，服务端做确认动作，这是客户端因为已经忽略该请求，到时服务端在该次连接上的无效等待，从而造成资源的浪费。
四次挥手：
- 第一次挥手：客户端发出连接释放请求，此时处于等待1状态(FIN-WAIT-1)
- 第二次挥手：服务端发出确认，并进入关闭等待状态(CLOSE-WAIT)，此时客户端收到后，进入等待2状态(FIN-WAIT-2)
- 第三次挥手：服务端发出连接释放动作，进入确认状态（LAST-ACK）
- 第四次挥手：客户端收到释放动作进入等待状态(TIMIE-WAIT)，服务端收到进入关闭状态(CLOSED),客户端在等待一段时间后也进入关闭状态（2MSL）
为什么断开连接要4次:tcp协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。两个连接断开是双向的，A向B断开，B确认。此时B依然可以通信A，这时就是B向A断开，A确认。

TIME_WAIT和CLOSE_WAIT的区别。

TIME_WAIT是主动关闭连接时形成的，等待2MSL时间，约4分钟，防止最后一个释放确认动作丢失。
CLASE_WAIT是被动关闭连接形成的。服务端收到客户端的释放连接请求并进行确认胡进入CLOSE_WAIT状态。如果服务器端不执行close，就不能由CLOSE_WAIT迁移到LAST_ACK.

说说你知道的几种HTTP响应码，比如200, 302, 404。

200：请求成功
302：临时性重定向
404：请求资源服务器未找到
500：服务器遇到未知情况
502：请求未完成。服务器从上游服务器收到一个无效的响应。
100：服务器收到部分请求。

当你用浏览器打开一个链接（如：http://www.javastack.cn）的时候，计算机做了哪些工作步骤。

dns解析–>端口分析–>tcp请求–>服务器处理请求–>服务器响应–>浏览器解析—>连接关闭

TCP/IP如何保证可靠性，说说TCP头的结构。

TCP/IP如何保证可靠性
- 校验和：发送方在发送数据之前计算校验和并填充，接收方收到数据后，对数据以同样的方式进行计算求出校验和并对比
- 确认应答与序列号：tcp传输过程中，每次接收方收到数据后，都会对传输方进行确认瘾大。也就是放松ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
- 超时重传：发送方在发送完数据后等待一段时间，时间到后没有收到报文信息，那么对刚才发送的数据进行重新发送。等待的时长是动态计算的，例如：linux , 初始超时500ms，后续等待已2的指数增长：2 * 500、4 * 500
- 连接管理：三次握手、四次挥手保证连接可靠
- 流量控制：接收端会在tcp协议的报文头信息当中，指定接收数据大小，客户端根据该配置发送指定数量的数据。
- 拥塞控制：tcp引入慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态，再决定多大的速度传输
TCP头的结构
- 16位端口号：告知主机该报文段来自哪里(源端口)，以及传给那个上层协议或应用程序(目的端口)
- 32位序列号：一次tcp通信过程中某一个传输方向上的字节流的问个字节的编号。
- 32位确认好：用作对另一方发送来的tcp报文段的响应。
- 4位头部长度：标识该tcp头部有杜少个32bit字
- 6位标志位：配置标志位指定功能
- 16位窗口大小：流量控制
- 16位校验和：校验和
- 16位紧急指针
- 16位选项

如何避免浏览器缓存

Cache-Control/Pragma 设置 no-cache 告知不缓存
过期时间设置为0： Expires = 0
对请求资源你添加版本号例如：xx.js?version=1

如何理解HTTP协议的无状态性。

服务端对于客户端每次发送的请求都认为它是一个新的请求，上一次会话和下一次会话没有联系；http协议这种特性优点在于解放了服务器，每次请求点到为止，不会造成不必要连接占用，缺点在于每次请求会传输大量重复的内容信息。

简述Http请求get和post的区别以及数据包格式。

get/post区别
- 在客户端，Get方式在通过URL提交数据，数据在URL中可以看到；POST方式，数据放置在body体内提交。
- 在HTTP规范中，没有对URL的长度和传输的数据大小进行限制。但是在实际开发过程中，对于GET，特定的浏览器和服务器对URL的长度有限制。对于POST，由于不是URL传值，理论上是不会受限制的，但是实际上各个服务器会规定对POST提交数据大小进行限制
- 安全性。使用 Get 的时候，参数会显示在地址栏上，而 Post 不会。所以，如果这些数据是中文数据而且是非敏感数据，那么使用 get；如果用户输入的数据不是中文字符而且包含敏感数据，那么还是使用 post为好。
- GET在浏览器回退时是无害的，而POST会再次提交请求
- GET请求会被浏览器主动cache，而POST不会，除非手动设置。
数据包：Get产生一个TCP数据包；Post产生两个TCP数据包。
- 对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
- 对于POST，浏览器先发送header，服务器响应100（continue），然后再发送data，服务器响应200（返回数据）；

HTTP有哪些method

get: 请求制定页面信息，并返回实体
head: 功能类似于get请求，不过返回的响应中没有具体内容，用于获取报头
post: 想制定资源体骄傲数据进行处理请求
put: 从客户端向服务起传送数据
delete: 请求删除
options: 客户端查看服务起性能
link: 请求服务起建立链接关系
。。。。。等等

简述HTTP请求的报文格式。

http 请求报文由请求行、请求头、请求包体 4个部分组成。
- 请求行：由3部分组成，分别为：请求方法、URL以及协议版本，之间由空格分隔
- 请求头部：请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔。如：ua、host
- 请求包体：可选部分，get请求可无。

HTTP的长连接是什么意思。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：Connection:keep-alive.在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTPS的加密方式是什么，讲讲整个加密解密流程。

加密方式：非对称加密和对称加密协调配合。
整个流程大概：
- 客户端发起https请求
- 服务端配置证书
- 传送证书：这个证书其实是公钥，包含了很多信息，如证书的颁发机构，过期时间。
- 客户端解析证书：客户端的TLS负责解析证书，验证公钥的有效性。验证后生成一个随机值，用证书对随机值进行加密
- 传送加密信息
- 服务端解密信息：服务端用私钥解密，得到客户端的随机值，服务端通过这个随机值进行对称加密，随机值即作为加解密的钥匙
- 传输加密后的信息
- 客户端解密信息

Http和https的区别。

https协议需要到ca申请证书或自制证书。
http的信息是明文传输，https则是具有安全性的ssl加密。
http是直接与TCP进行数据传输，而https是经过一层SSL（OSI表示层），用的端口也不一样，前者是80（需要国内备案），后者是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

什么是分块传送。

HTTP1.1 协议（RFC2616）开始支持获取文件的部分内容，这为并行下载以及断点续传提供了技术支持。它通过在 Header 里两个参数实现的，客户端发请求时对应的是 Range ，服务器端响应时对应的是 Content-Range。

Session和cookie的区别。

cookie数据存放在客户的浏览器上，session数据放在服务器上。
Cookie的安全性一般，他人可通过分析存放在本地的Cookie并进行Cookie欺骗。在安全性第一的前提下，选择Session更优。重要交互信息比如权限等就要放在Session中，一般的信息记录放Cookie就好了
单个Cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个Cookie。
Session 可以放在文件、数据库或内存中，比如将Session保存在redis中。由于一定时间内它是保存在服务器上的，当访问增多时，会较大地占用服务器的性能。考虑到减轻服务器性能方面，应当适时使用Cookie。
Session 的运行依赖Session ID，而 Session ID 是存在 Cookie 中的，也就是说，如果浏览器禁用了 Cookie，Session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 Session ID）。
用户验证这种场合一般会用 Session。因此，维持一个会话的核心就是客户端的唯一标识，即Session ID。