获取方式:关注公众号,回复 面试手册;(文末也可获取)
小熊学Java在线网站:https://javaxiaobear.gitee.io/
网络的七层架构从下到上主要包括物理层、数据链路层、网络层、传输层、会话层、表示层和应用层;
TCP/IP 不是指TCP 和IP 这两个协议的合称, 而是指因特网的整个TCP/IP 协议簇。 网络接口层:定义了主机间网络连通的协议,具体包括Echernet 、FDDI 、ATM 等通信协议 网络层:主要用于数据的传输、路由及地址的解析,以保障主机可以把数据发送给任何网络上的目标。数据经过网络传输,发送的顺序和到达的顺序可能发生变化。在网络层使用IP ( Internet Protocol )和地址解析协议( ARP ) 传输层:使源端和目的端机器上的对等实体可以基于会话相互通信。在这一层定义了两个端到端的协议TCP 和UDP 。TCP 是面向连接的协议,提供可靠的报文传输和对上层应用的连接服务,除了基本的数据传输,它还有可靠性保证、流量控制、多路复用、优先权和安全性控制等功能。UDP 是面向无连接的不可靠传输的协议,主要用于不需要TCP 的排序和流量控制等功能的应用程序 应用层:负责具体应用层协议的定义,包括
官方回答:
非官方解释三次握手 第一次握手:客户端发送网络包,服务端收到了。服务端得出结论:客户端的发送能力、服务端的接收能力是正常的。 第二次握手:服务端发包,客户端收到了。客户端得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。 第三次握手:客户端发包,服务端收到了。服务端得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。 三次握手能防止历史连接的建立,能减少双方不必要的资源开销,能帮助双方同步初始化序列号 不使用「两次握手」和「四次握手」的原因:
TCP 在建立连接时要进行三次握手,在断开连接时要进行四次挥手,这是由于TCP的半关闭造成的。因为TCP 连接是全双工的(即数据可在两个方向上同时传递),所以在进行关闭时对每个方向都要单独进行关闭,这种单方向的关闭叫作半关闭。在二方完成它的数据发送任务时,就发送一个FIN 来向另一方通告将要终止这个方向的连接。
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
MSL(Maximum Segment Lifetime),TCP允许不同的实现可以设置不同的MSL值。
HTTP 是一个无状态的协议。无状态是指客户机(Web 浏览器)和服务器之间不需要建立持久的连接,这意味着当一个客户端向服务器端发出请求,然后服务器返回响应(response),连接就被关闭了,在服务器端不保留连接的有关信息 HTTP 遵循请求(Request)/应答(Response)模型。客户机(浏览器)向服务器发送请求,服务器处理请求并返回适当的应答。所有HTTP 连接都被构造成一套请求和应答。
当浏览器第一次发送请求给服务器时,服务器响应了;如果同个浏览器发起第二次请求给服务器时,它还是会响应,但是呢,服务器不知道你就是刚才的那个浏览器。简言之,服务器不会去记住你是谁,所以是无状态协议.
简化版区别: HTTP/1.0:默认是短连接,可以强制开启,通过加入Connection: keep - alive
HTTP/1.1:默认为长连接
HTTP/2.0:多路复用
区别 | TCP | UDP |
---|---|---|
可靠性传输 | 可靠 | 不可靠 |
连接 | 面向连接 | 无连接 |
传输数据有序性 | 有序 | 无序 |
传输速度 | 相对UDP较慢 | 较快 |
流量控制和拥塞控制 | 有 | 没有 |
字节 | 首部有20字节 | 首部有8字节 |
报文格式 | 面向字节流 | 面向报文 |
适用场景 | 网页、邮件 | 语音广播 |
通过在头部(请求和响应头)设置Connection字段指定为keep-alive
,HTTP/1.0协议支持,但是是默认关闭的,从HTTP/1.1以后,连接默认都是长连接。
HTTP一般会有httpd守护进程,里面可以设置keep-alive timeout,当tcp连接闲置超过这个时间就会关闭,也可以在HTTP的header里面设置超时时间;TCP 的keep-alive包含三个参数,支持在系统内核的net.ipv4里面设置;当 TCP 连接之后,闲置了tcp_keepalive_time,则会发生侦测包,如果没有收到对方的ACK,那么会每隔 tcp_keepalive_intvl再发一次,直到发送了tcp_keepalive_probes,就会丢弃该连接。
1. tcp_keepalive_intvl = 15
2. tcp_keepalive_probes = 5
3. tcp_keepalive_time = 1800
状态码 | 类别 |
---|---|
1XX | 信息性状态码 |
2XX | 成功类状态码 |
3XX | 重定向状态码 |
4XX | 客户端错误状态码 |
5XX | 服务端错误状态码 |
HTTPS 是以安全为目标的HTTP 通道,它在HTTP 中加入SSL 层以提高数据传输的安全性。 HTTP 被用于在Web 浏览器和网站服务器之间传递信息,但以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了Web 浏览器和网站服务器之间的传输报文,就可以直接读懂其中的信息,因此HTTP 不适合传输一些敏感信息,比如身份证号码、密码等。为了数据传输的安全, HTTPS 在HTTP 的基础上加入了SSL 协议,SSL 依靠证书来验证服务器的身份,并对浏览器和服务器之间的通信进行数据加密,以保障数据传输的安全性,其端口一般是443 。
HTTP | HTTPS | |
---|---|---|
安全性 | 不安全 | 安全 |
默认端口 | 80 | 443 |
资源消耗 | 较少 | 较多 |
是否需要证书 | 不需要 | 需要 |
报文是否加密 | 明文 | 密文 |
请求方式 | 用途 |
---|---|
GET | 对服务资源获取的简单请求 |
POST | 用于发送包含用户提交数据的请求 |
PUT | 向服务提交数据,以修改数据 |
DELETE | 删除服务器上的某些资源 |
HEAD | 请求页面的首部,获取资源的元信息 |
CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器 |
OPTIONS | 允许客户端查看服务器的性能 |
TRACE | 回显服务器收到的请求,主要用于测试或诊断 |
PATCH | 是对 PUT 方法的补充,用来对已知资源进行局部更新 |
TCP是面向流,没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题
为什么会产生粘包和拆包呢?
如何解决?
TCP三次握手,发送端和接收端进入到ESTABLISHED状态,它们即可以愉快地传输数据啦。 但是发送端不能疯狂地向接收端发送数据,因为接收端接收不过来的话,接收方只能把处理不过来的数据存在缓存区里。如果缓存区都满了,发送方还在疯狂发送数据的话,接收方只能把收到的数据包丢掉,这就浪费了网络资源啦 TCP 提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量,这就是流量控制
一般可以这么认为,IP地址=网络号+主机号。
IP地址分为A,B,C,D,E五大类:
ARP 协议协议,Address Resolution Protocol,地址解析协议,它是用于实现IP地址到MAC地址的映射 当源主机和目的主机要进行通信时
基于TCP的应用层协议有:HTTP、FTP、SMTP、TELNET、SSH
基于UDP的应用层协议:DNS、TFTP、SNMP
URI像是身份证,可以唯一标识一个人,而URL更像一个住址,可以通过URL找到这个人
官方回答:TCP拥塞控制是传输控制协议(英语:Transmission Control Protocol,缩写TCP)避免网络拥塞的算法,是互联网上主要的一个拥塞控制措施。它使用一套基于线增积减模式的多样化网络拥塞控制方法(包括慢启动和拥塞窗口等模式)来控制拥塞。 拥塞控制,控制的目的就是避免「发送方」的数据填满整个网络。 为了在「发送方」调节所要发送数据的量,定义了一个叫做「拥塞窗口」的概念 拥塞窗口 cwnd是发送方维护的一个的状态变量,它会根据网络的拥塞程度动态变化的。 拥塞窗口
cwnd
变化的规则:
cwnd
就会增大;cwnd
就减少其实只要「发送方」没有在规定时间内接收到 ACK 应答报文,也就是发生了超时重传,就会认为网络出现了拥塞
具体详情参考文章:https://xiaolincoding.com/network/3_tcp/tcp_feature.html#%E9%87%8D%E4%BC%A0%E6%9C%BA%E5%88%B6
TCP 连接在 Linux 内核中是一个名为
struct socket
的结构体,该结构体的内容包含 TCP 连接的状态等信息。当拔掉网线的时候,操作系统并不会变更该结构体的任何内容,所以 TCP 连接的状态也不会发生改变。
从协议本身来说,HTTPS协议目前是没有任何漏洞的,即使你成功进行中间人攻击,本质上是利用了客户端的漏洞(用户点击继续访问或者被恶意导入伪造的根证书),并不是 HTTPS 不够安全。
HTTP 由于是明文传输,所以安全上存在以下三个风险:
HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS
协议,可以很好的解决了上述的风险:
混合加密的方式实现信息的机密性,解决了窃听的风险。 摘要算法的方式来实现完整性,它能够为数据生成独一无二的「指纹」,指纹用于校验数据的完整性,解决了篡改的风险。 将服务器公钥放入到数字证书中,解决了冒充的风险。
可以。 传输层的「端口号」的作用,是为了区分同一个主机上不同应用程序的数据包。 传输层有两个传输协议分别是 TCP 和 UDP,在内核中是两个完全独立的软件模块。 当主机收到数据包后,可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP,所以可以根据这个信息确定送给哪个模块(TCP/UDP)处理,送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。
如果两个 TCP 服务进程同时绑定的 IP 地址和端口都相同,那么执行 bind() 时候就会出错,错误是“Address already in use” 如果两个TCP服务进程绑定的IP地址不同,端口相同,则可以绑定(不包含0.0.0.0,可以代表任意地址)
在客户端执行 connect 函数的时候,只要客户端连接的服务器不是同一个,内核允许端口重复使用。 TCP 连接是由四元组(源IP地址,源端口,目的IP地址,目的端口)唯一确认的,那么只要四元组中其中一个元素发生了变化,那么就表示不同的 TCP 连接的。 所以,如果客户端已使用端口 64992 与服务端 A 建立了连接,那么客户端要与服务端 B 建立连接,还是可以使用端口 64992 的,因为内核是通过四元祖信息来定位一个 TCP 连接的,并不会因为客户端的端口号相同,而导致连接冲突的问题。
要看客户端是否都是与同一个服务器(目标地址和目标端口一样)建立连接。 如果客户端都是与同一个服务器(目标地址和目标端口一样)建立连接,那么如果客户端 TIME_WAIT 状态的连接过多,当端口资源被耗尽,就无法与这个服务器再建立连接了。即使在这种状态下,还是可以与其他服务器建立连接的,只要客户端连接的服务器不是同一个,那么端口是重复使用的。
HTTPS 是先进行 TCP 三次握手,再进行 TLSv1.2 四次握手 同时握手的前提:
TCP 的连接状态查看,在 Linux 可以通过
netstat -napt
命令查看
当客户端想和服务端建立 TCP 连接的时候,首先第一个发的就是 SYN 报文,然后进入到 SYN_SENT
状态。
此时客户端迟迟收不到服务端发送的SYN+ACK报文,就会触发超时重传机制,重传 SYN 报文,而且重传的 SYN 报文的序列号都是一样的
在 Linux 里,客户端的 SYN 报文最大重传次数由 tcp_syn_retries
内核参数控制,这个参数是可以自定义的,默认值一般是 5。
# cat /proc/sys/net/ipv4/tcp_syn_retries
5
通常,第一次超时重传是在 1 秒后,第二次超时重传是在 2 秒,第三次超时重传是在 4 秒后,第四次超时重传是在 8 秒后,第五次是在超时重传 16 秒后。没错,每次超时的时间是上一次的 2 倍。
当第五次超时重传后,会继续等待 32 秒,如果服务端仍然没有回应 ACK,客户端就不再发送 SYN 包,然后断开 TCP 连接。
tcp_syn_retries
内核参数决定;tcp_synack_retries
内核参数决定第三次握手过程:客户端收到服务端的 SYN-ACK 报文后,就会给服务端回一个 ACK 报文,也就是第三次握手,此时客户端状态进入到
ESTABLISH
状态。 因为这个第三次握手的 ACK 是对第二次握手的 SYN 的确认报文,所以当第三次握手丢失了,如果服务端那一方迟迟收不到这个确认报文,就会触发超时重传机制,重传 SYN-ACK 报文,直到收到第三次握手,或者达到最大重传次数。 注意,ACK 报文是不会有重传的,当 ACK 丢失了,就由对方重传对应的报文。
扫码关注腾讯云开发者
领取腾讯云代金券
Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号:粤B2-20090059 深公网安备号 44030502008569
腾讯云计算(北京)有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287
Copyright © 2013 - 2025 Tencent Cloud.
All Rights Reserved. 腾讯云 版权所有