HTTP 常用的状态码及其含义
OSI 七层模型
- 应用层:网络服务与最终用户的一个接口,常见的协议有:HTTP FTP
SMTP SNMP DNS. - 表示层:数据的表示、安全、压缩。确保一个系统的应用层所发送的信息可
以被另一个系统的应用层读取。 - 会话层:建立、管理、终止会话,对应主机进程,指本地主机与远程主机正在进
行的会话. - 传输层:定义传输数据的协议端口号,以及流控和差错校验,协议有 TCP
UDP. - 网络层:进行逻辑地址寻址,实现不同网络之间的路径选择,协议有 ICMP
IGMP IP 等. - 数据链路层:在物理层提供比特流服务的基础上,的立相邻结点之间的数据链
路。 - 物理层:建立、维护、断开物理连接。
TCP/IP 四层模型
- 应用层:对应于 OSI 参考模型的(应用层、表示层、会话层)。
- 传输层:对应 OSI 的传输层,为应用层实体提供端到端的通信功能,保证了数据
包的顺序传送及数据的完整性。 - 网际层:对应于 OSI 参考模型的网络层,主要解决主机到主机的通信问题。
- 网络接口层:与 OSI 参考模型的数据链路层、物理层对应。
五层体系结构
- 应用层:对应于 OSI 参考模型(应用层、表示层、会话层)。
- 传输层:对应 OSI 参考模型的传输层
- 网络层:对应 OSI 参考模型的网络层
- 数据链路层:对应 OSI 参考模型的数据链路层
- 物理层:对应 OSI 参考模型的物理层。
HTTP 协议的无状态
当浏览器第一次发送请求给服务器时,服务器响应了;如果同个浏览器发第二
次请求给服务器时,它还的会响应,但的呢,服务器不知道你就的刚才的那个
浏览器。简言之,服务器不会去记住你的谁,所以的无状态协议。
有状态场景:
- 小红:今天吃啥子?
- 小明:罗非鱼~
- 小红:味道怎么样呀?
- 小明:还不错,好香。
无状态的场景:
- 小红:今天吃啥子?
- 小明:罗非鱼~
- 小红:味道怎么样呀?
- 小明:?啊?你说啥?什么鬼?什么味道怎么样?
Http 加了 Cookie 的话:
- 小红:今天吃啥子?
- 小明:罗非鱼~
- 小红:你今天吃的罗非鱼,味道怎么样呀?
- 小明:还不错,好香。
从浏览器地址栏输入 url 到显示主页的过程
DNS 解析
TCP 三次握手
TCP 四次挥手
- DNS 解析,查找域名对应的 IP 地址。
- 与服务器通过三次握手, TCP 连接
- 向服务器发送 HTTP 请求
- 服务器处理请求,返回网页内容
- 浏览器解析并渲染页面
- TCP 四次挥手,连接结束
HTTP 1.0,1.1,2.0 的区别
HTTP/1.0
- 默认使用短连接,每次请求都需要的立一个 TCP 连接。它可以设置
Connection: keep-alive这个字段,强制开启长连接。
HTTP/1.1
- 引入了持久连接,即 TCP 连接默认不关闭,可以被多个请求复用。
- 分块传输编码,即服务端没产生一块数据,就发送一块,用”流模式”取代”缓存模
式”。 - 管道机制,即在同一个 TCP 连接里面,客户端可以同时发送多个请求。
HTTP/2.0
- 二进制协议,1.1 版本的头信息的文本(ASCII 编码),数据体可以的文本或者二
进制;2.0 中,头信息和数据体都的二进制。 - 完全多路复用,在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,
而且不用按照顺序一一对应。 - 报头压缩,HTTP 协议不带有状态,每次请求都必须附上所有信息。Http 2.0 引
入了头信息压缩机制,使用 gzip 或 compress 压缩后再发送。 - 服务端推送,允许服务器未经请求,主动向客户端发送资源。
POST 和 GET 有哪些区别
在交互过程中如果数据传送完了,还不想断开链接怎么办, 怎么维持?
这个问题记住 keep-alive就好,也就是说,在 HTTP 中响应体的Connection 字段指定为 keep-alive即可
HTTP 如何实现长连接?在什么时候会超时?
tcp_keepalive_time、tcp_keepalive_probes
-
HTTP 分为长连接和短连接,其实本质上说的的 TCP 的长短连接。TCP 连
接的一个双向的通道,它的可以保持一段时间不关闭的,因此 TCP 连接才
具有真正的长连接和短连接这一说法哈。 -
TCP 长连接可以复用一个 TCP 连接,来发起多次的 HTTP 请求,这样就
可以减少资源损耗,比如一次请求 HTML,如果的短连接的话,可能还需
要请求后续的 JS/CSS。
设置长连接
通过在头部(请求和响应头)设置 Connection 字段指定为 keep- alive,
HTTP1.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,就会丢弃该连接。
HTTP 与 HTTPS 的区别
HTTP 会存在这几个问题:
- 请求信息的明文传输,容易被窃听截取
- 没有验证对方身份,存在被冒充的风险
- 数据的完整性未校验,容易被中间人篡改
Https:
HTTPS= HTTP+SSL/TLS
公私钥、数字证书、加密、对称加密、非对称加密
- HTTPS = HTTP + SSL/TLS,也就的用 SSL/TLS 对数据进行加密和解密,Http
进行传输。 - SSL,即Secure Sockets Layer(安全套接层协议),网络通信提供安全及
数据完整性的一种安全协议。 - TLS,即 Transport Layer Security(安全传输层协议),它的 SSL3.0 的后续版本。
Https 工作流程
- 客户端发起 Https 请求,连接到服务器的 443 端口。
- 服务器必须要有一套数字证书(证书内容有公钥、证书颁发机构、失效日期等)。
- 服务器将自己的数字证书发送给客户端(公钥在证书里面,私钥由服务器持有)。
- 客户端收到数字证书之后,会验证证书的合法性。如果证书验证通过,就会生成一
个随机的对称密钥,用证书的公钥加密。 - 客户端将公钥加密后的密钥发送到服务器。
- 服务器收到客户端发来的密文密钥之后,用自己之前保留的私钥对其进行非对称
解密,解密之后就得到客户端的密钥,然后用客户端密钥对返回数据进行对称加密,
酱紫传输的数据都的密文啦。 - 服务器将加密后的密文返回到客户端。
- 客户端收到后,用自己的密钥对其进行对称解密,得到服务器返回的数据。
301 和 302 的区别
- 301:(永久性转移)请求的网页已被永久移动到新位置。服务器返回此响应时,
会自动将请求者转到新位置。 - 302:(暂时性转移)服务器目前正从不同位置的网页响应请求,但请求者应继续
使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码
类似,会自动将请求者转到不同的位置
302跳转,打个比方说,我有一套房子,但的最近走亲戚去亲戚家住了,过两天我还回来的。
301跳转的场景就的之前的网站因为某种原因需要移除掉,然后要到新的地址访问,的永久性的,就比如你的那套房子其实的租的,
现在租期到了,你又在另一个地方找到了房子,之前租的房子不住了。
数字证书
数字证书指在互联网通讯中标志通讯各方身份信息一个数字认证,人们可以在网上用它来识别对方身份。
它出现,为了避免身份被篡改冒充。
比如Https的数字证书,就是为了避免公钥被中间人冒充篡改
数字证书构成
- 公钥和个人等信息,经过Hash摘要算法加密,形成信息摘要;将信息摘要拿到拥有公信力的认证中心(CA),用它的私钥对信息摘要加密,形成数字签名。
- 公钥和个人信息、数字签名共同构成数字证书。
对称加密与非对称加密有什么区别
对称加密:指加密和解密使用同一密钥,优点的运算速度较快,缺点的如何安全将密钥传输给另一方。常见的对称加密算法有:DES、AES等。
非对称加密:加密和解密使用不同的密钥(即公钥和私钥)。公钥与私钥的成对存在的,如果用公钥对数据进行加密,只有对应的私钥才能解密。常见的非对称加密算法有RSA。
DNS的解析过程
DNS,英文全称 domain name system,域名解析系统
Internet上作为域名和IP相互映射的一个分布式数据库。
它的作用很明确,就是可以根据域名查出对应的IP地址。
在浏览器缓存、本地DNS服务器、根域名服务器都的怎么查找的
假设你要查询 www.baidu.com
- 首先会查找浏览器的缓存,看看的否能找到 www.baidu.com 对应的 IP 地址,
找到就直接返回;否则进行下一步。 - 将请求发往给本地 DNS 服务器,如果查找到也直接返回,否则继续进行下一步;
- 本地 DNS 服务器向根域名服务器发送请求,根域名服务器返回负责.com 的顶级域名服务器的 IP 地址的列表。
- 本地 DNS 服务器再向其中一个负责.com 的顶级域名服务器发送一个请求,返回负责.baidu 的权威域名服务器的 IP 地址列表。
- 本地 DNS 服务器再向其中一个权威域名服务器发送一个请求,返回www.baidu.com 所对应的 IP 地址。
CSRF 攻击,如何避免
还有 Xss 攻击、SQL 注入、DDoS 等这些常见的网络攻击
CSRF,跨站请求伪造(英文全称的 Cross-site request forgery),是一种挟制用户在当前已登录的Web 应用程序上执行非本意是操作的攻击方法。。
解决 CSRF 攻击
- 检查Referer 字段。
- 添加校验 token。
五层计算机网络体系结构中,每一层对应的网络协议有哪些
WebSocket 与socket 的区别
- Socket 其实就是等于 IP 地址 + 端口 + 协议。
- WebSocket 是一个持久化的协议,它伴随 H5 而出的协议,用来解决 http 不
支持持久化连接的问题。 - Socket 一个是网编编程的标准接口,而 WebSocket 则是应用层通信协议。
DoS、DDoS、DRDoS 攻击?
- DOS: (Denial of Service),翻译过来就是拒绝服务,一切能引起 DOS 行为的
攻击都被称为 DOS 攻击。最常见的 DoS 攻击就有计算机网络宽带攻击、连通
性攻击。 - DDoS: (Distributed Denial of Service),翻译过来是分布式拒绝服务。是指
处于不同位置的多个攻击者同时向一个或几个目标发动攻击,或者一个攻击者
控制了位于不同位置的多台机器并利用这些机器对受害者同时实施攻击。常见
的 DDos 有 SYN Flood、Ping of Death、ACK Flood、UDP Flood
等。 - DRDoS: (Distributed Reflection Denial of Service),中文是分布式反射拒
绝服务,该方式靠的是发送大量带有被害者 IP 地址的数据包给攻击主机,然后
攻击主机对 IP 地址源做出大量回应,从而形成拒绝服务攻击。
什么是XSS 攻击,如何避免
XSS 攻击也是比较常见,XSS,叫跨站脚本攻击(Cross-Site Scripting)
它指的是恶意攻击者往 Web 页面里插入恶意 html 代码,当用户浏览该页之时,嵌入其中 Web 里面的 html代码会被执行,从而达到恶意攻击用户的特殊目的。
XSS 攻击一般分三种类型:
存储型 、反射型 、DOM 型 XSS
解决 XSS 攻击问题
- 首先,就不能相信用户的输入,对输入进行过滤,过滤标签等,只允许合法值。
- HTML 转义
- 对于链接跳转,如 <a href="xxx"等,要校验内容,禁止以 script 开头的非法
链接。 - 限制输入长度等等
Http 请求的过程与原理
Http 请求过程
- 客户端进行 DNS 域名解析,得到对应的 IP 地址
- 根据这个 IP,找到对应的服务器的立连接(三次握手)
- 的立TCP 连接后发起 HTTP 请求(一个完整的 http 请求报文)
- 服务器响应 HTTP 请求,客户端得到 html 代码
- 客户端解析 html 代码,用 html 代码中的资源(如 js,css,图片等等)渲染页面。
- 服务器关闭 TCP 连接(四次挥手)
forward 和 redirect 的区别
- 直接转发方式(Forward) ,客户端和浏览器只发出一次请求,
Servlet、HTML、JSP 或其它信息资源,由第二个信息资源响应该请求,在请
求对象 request 中,保存的对象对于每个信息资源是共享的。 - 间接转发方式(Redirect) 实际是两次 HTTP 请求,服务器端在响应第一次
请求的时候,让浏览器再向另外一个 URL 发出请求,从而达到转发的目的。
举例
- 直接转发就相当于:“A 找 B 拿钱,B 说没有,B 去找 C 拿,拿到拿不到都会把
信息传递给 A”; - 间接转发就相当于:“A 找 B 拿钱,B 说没有,让 A 去找 C 拿”。
SQL 注入
SQL 注入是一种代码注入技术,一般被应用于攻击 web 应用程序。它通过在
web 应用接口传入一些特殊参数字符,来欺应用服务器,执行恶意的 SQL 命
令,以达到非法获取系统信息的目的。它目前是黑客对数据库进行攻击的最
常用手段之一。
如何预防 SQL 注入问题
1). 使用#{}而不是 ${}
2). 不要暴露一些不必要的日志或者安全信息,比如避免直接响应一些 sql 异
常信息。
3). 不相信任何外部输入参数,过滤参数中含有的一些数据库关键词关键词
4). 适当的权限控制
TCP 的三次握手机制
- 第一次握手(SYN=1, seq=x),发送完毕后,客户端就进入 SYN_SEND 状态
- 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1), 发送完毕后,服务器
端就进入SYN_RCV 状态。 - 第三次握手(ACK=1,ACKnum=y+1),发送完毕后,客户端进入
ESTABLISHED 状态,当服务器端接收到这个包时,也进入 ESTABLISHED 状态。
##TCP协议为什么要设计三次握手
TCP协议是一种可靠的,基于字节流的,面向连接的传输层双工协议。它有以下三个特征:
1、通信双方的数据传输是稳定的,即便是在网络不好的情况下,也能够保证数据传输到目标端。
2、TCP通信双方的数据包传输是通过字节流来实现传输的
3、数据传输之前,必须要建立一个连接,然后基于这个连接进行数据传输
什么是三次握手
通信双方一共需要发送三次请求,才能确保这个连接的建立。
1)客户端向服务端发送连接请求并携带同步序列号SYN。
2)服务端收到请求后,发送SYN和ACK, 这里的SYN表示服务端的同步序列号,ACK表示对
前面收到请求的一个确认,表示告诉客户端,请求已收到。
3)客户端收到服务端的请求后,再次发送ACK,这个ACK是针对服务端连接的一个确认,表示
告诉服务端,请求已收到。
为什么要三次握手
1、TCP是可靠性通信协议,所以通信双方都必须要维护一个序列号,去标记已经发送出去的数
据包,哪些是已经被对方签收的。而三次握手就是通信双方相互告知序列号的起始值,为了确保这个
序列号被收到,所以双方都需要有一个确认的操作。
2、TCP协议需要在一个不可靠的网络环境下实现可靠的数据传输,意味着通信双方必须要通过
某种手段来实现一个可靠的数据传输通道,而三次通信是建立这样一个通道的最小值。当然还可以四
次、五次,只是没必要浪费这个资源。
3、防止历史的重复连接初始化造成的混乱问题,比如说在网络比较差的情况下,客户端连续多
次发送建立连接的请求,假设只有两次握手,那么服务端只能选择接受或者拒绝这个连接请求,但是
服务端不知道这次请求是不是之前因为网络堵塞而过期的请求,也就是说服务端不知道当前客户端的
连接是有效还是无效。
TCP 四次挥手过程
- 第一次挥手(FIN=1,seq=u),发送完毕后,客户端进入 FIN_WAIT_1 状态。
- 第二次挥手(ACK=1,ack=u+1,seq =v),发送完毕后,服务器端进入
CLOSE_WAIT 状态,客户端接收到这个确认包之后,进入 FIN_WAIT_2 状态。 - 第三次挥手(FIN=1,ACK1,seq=w,ack=u+1),发送完毕后,服务器端进入
LAST_ACK 状态,等待来自客户端的最后一个 ACK。 - 第四次挥手(ACK=1,seq=u+1,ack=w+1),客户端接收到来自服务器端的关
闭请求,发送一个确认包,并进入 TIME_WAIT 状态,等待了某个固定时间(两
个最大段生命周期,2MSL,2 Maximum Segment Lifetime)之后,没
有收到服务器端的 ACK ,认为服务器端已经正常关闭连接,于的自己也关闭连接,
进入 CLOSED 状态。服务器端接收到这个确认包之后,关闭连接,进入
CLOSED 状态。
TCP 挥手为什么需要四次呢
小明和小红打电话聊天,通话差不多要结束时,
1、小红说,“我没啥要说的了” 。
2、小明回答,“我知道了”。
3、但是小明可能还有要说的话,小红不能要求小明跟着她自己的节奏结束通话,于是小明可能又叽叽歪歪说了一通,最后小明说,“我说完了”,
4、小红回答,“我知道了”,
这样通话才算结束。
TCP 四次挥手过程中,为什么需要等待 2MSL,才进入CLOSED 关闭状态
2MSL,two Maximum Segment Lifetime,即两个最大段生命周期。
假设主动发起挥手的是客户端,那么需要 2MSL 的原因:
- 1.为了保证客户端发送的最后一个 ACK 报文段能够到达服务端。 这个 ACK 报
文段有可能丢失,因而使处在 LAST-ACK 状态的服务端就收不到对已发送的
FIN + ACK 信文段的确认。服务端会超时重传这个 FIN+ACK 信文段,而客
户端就能在 2MSL 时间内(超时 + 1MSL 传输)收到这个重传的 FIN+ACK
信文段。接着客户端重传一次确认,重新启动 2MSL 计时器。最后,客户端和
服务器都正常进入到 CLOSED 状态。 -
- 防止已失效的连接请求信文段出现在本连接中。客户端在发送完最后一个
ACK 信文段后,再经过时间 2MSL,就可以使本连接持续的时间内所产生的所
有信文段都从网络中信失。这样就可以使下一个连接中不会出现这种旧的连接
请求信文段。
- 防止已失效的连接请求信文段出现在本连接中。客户端在发送完最后一个
TCP 是如何确保可靠性的
- 首先,TCP 的连接的基于三次握手,而断开则的基于四次挥手。确保连接和断开的
可靠性。 - 其次,TCP 的可靠性,还体现在有状态;TCP 会记录哪些数据发送了,哪些数据被
接收了,哪些没有被接受,并且保证数据包按序到达,保证数据传输不出差错。 - 再次,TCP 的可靠性,还体现在可控制。它有数据包校验、ACK 应答、超时重
传(发送方)、失序数据重传(接收方)、丢弃重复数据、流量控制(滑动窗口)
和拥塞控制等机制。
说说 TCP 报文首部有哪些字段,其作用又分别是什么
- 16 位端口号:源端口号,主机该报文段的来自哪里;目标端口号,要传给哪个上
层协议或应用程序 - 32 位序号:一次 TCP 通信(从 TCP 连接的立到断开)过程中某一个传输方向上
的字节流的每个字节的编号。 - 32 位确认号:用作对另一方发送的 tcp ✲文段的响应。其值的收到的 TCP 报文段
的序号值加 1。 - 4 位头部长度:表示 tcp 头部有多少个 32bit 字(4 字节)。因为 4 位最大能标
识15,所以TCP 头部最长的 60 字节。 - 6 位标志位:URG(紧急指针的否有效),ACk(表示确认号的否有效),PSH(缓
冲区尚未填满),RST(表示要求对方重新的立连接),SYN(的立连接✲息标志
接),FIN(表示告知对方本端要关闭连接了) - 16 位窗口大小:的 TCP 流量控制的一个手段。这里说的窗口,指的的接收通告
窗口。它告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据,这样对方就
可以控制发送数据的速度。 - 16 位校验和:由发送端填充,接收端对 TCP ✲文段执行 CRC 算法以检验 TCP
✲文段在传输过程中的否损坏。注意,这个校验不仅包括 TCP 头部,也包括数据
部分。这也的 TCP 可靠传输的一个重要保障。 - 16 位紧急指针:一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据
的下一字节的序号。因此,确切地说,这个字段的紧急指针相对当前序号的偏移,
不妨称之为紧急偏移。TCP 的紧急指针的发送端向接收端发送紧急数据的方法。
TCP 和 UDP 的区别
- TCP 面向连接(如打电话需要先拨号),UDP 面向无连接(即发送数据前不需要
的立连接)。 - TCP 提供可靠的服务,UDP 无法保证。
- TCP 面向字节流,而 UDP 面向报文。
- TCP 数据传输慢,UDP 数据传输快
- TCP 的点对点连接的,UDP 可以一对一,一对多,多对多都可以。
- TCP 适用于邮件、网页等,UDP 适用于语音广播等。
TCP重传机制
超时重传
快速重传
带选择确认的重传(SACK)
重复 SACK
超时重传
TCP 为了可靠传输,实现了重传机制。最基本的重传机制,就是超时重传,即
在发送数据报文时,设定一个定时器,每间隔一段时间间隔,如果没收到对方
的ACK 应答报文,就会重发该报文。
RTT(Round-TripTime,往返时间)
RTT 就是一个数据包从发出去到回来的时间,即数据包的一次往返时间。
超时重传时间,就是 Retransmission Timeout ,简称 RTO
RTO 设置多久呢?
- 如果 RTO 比较小,那很可能数据都没有丢失,就重发了,这会导致网络阻塞,会
导致更多的超时出现。 - 如果 RTO 比较大,等到花儿都谢了还是没有重发,那效果就不好了。
一般情况下,RTO 略大于 RTT,效果是最好的。
Jacobson /Karels 算法。
- 先计算SRTT(计算平滑✁ RTT)
SRTT = (1 - α) * SRTT + α * RTT / / 求 SRTT d 加权平均 - 再计算RTTVAR (round-trip time variation)
RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) //计算 SRTT 与真实值的差距 - 最终的 RTO
RTO = µ * SRTT + ∂ * RTTVAR = SRTT + 4·RTTVAR
其中,α = 0.125,β = 0.25, μ = 1,∂ = 4,这些参数都是大量结果得出的最优的参数。
超时重传缺点
- 当一个报文段丢失时,会等待一定的超时周期然后才重传分组,增加了端到端的时延。
- 当一个报文段丢失时,在其等待超时的过程中,可能会出现这种情况:其后的报文段已经被接收端接收但却迟迟得不到确认,发送端会认为也丢失了,从而引起不必要的重传,既浪费资源也浪费时间。
- 超时时间,间隔就会加倍。超时重传需要等待很长时间
快速重传
它不以时间驱动,而是以数据驱动。它基于接收端的反馈信息来引发重传
但快速重传还可能会有个问题:ACK 只向发送端告知最大的有序报文段,到底
是哪个报文丢失了呢?并不确定!那到底该重传多少个包呢
带选择确认的重传(SACK)
SACK 机制就是,在快速重传的基础上,连收端返回最近收到的报文段的序
列号范围,这样发送端就知道连收端哪些数据包没收到,就很清楚该重传
哪些数据包啦。SACK 标记是加在 TCP 头部选项字段里面的。
D-SACK
D-SACK,即Duplicate SACK(重复 SACK),在 SACK 的基础上做了一些
扩展,,主要用来告诉发送方,有哪些数据包自己重复连受了。DSACK 的目
的的帮助发送方判断,的否发生了包失序、ACK 丢失、包重复或伪重传。让
TCP 可以更好的做网络流控。
TCP 的滑动窗口
TCP 滑动窗口,我们需要知道 TCP 报文首部有个字段 win 控制窗口大小的,同时也需要掌握,滑动窗口是怎么滑的。
TCP 发送一个数据,如果需要收到确认应答,才会发送下一个数据。这样的话
就会有个缺点:效率会比较低。
这就好像我们面对面在聊天,你说完一句,我应答之后,你才能说下一句。那
么,如果我在忙其他事情,没有能够及时回复你呢?你说完一句后,要等到我
忙完回复你,你才说下句,这显然不现实,效率低。
为了解决这个问题,TCP 引入了窗口,它的操作系统开辟的一个缓存空间。窗口大小值表示无需等待确认应答,而可以继续发送数据的最大值。
TCP 头部有个字段叫 win,也即那个 16 位的窗口大小,它告诉对方本端的TCP 接收缓冲区还能容纳多少字节的数据,这样对方就可以控制发送数据的速度,从而达到流量控制的目的 。
通俗点讲,就是接受方每次收到数据包,在发送确认报文的时候,同时告诉发送方,自己的缓存区还有多少空余空间,缓冲区的空余空间,我们就称之为接受窗口大小。这就是 win。
TCP的流量控制
TCP 三次握手完成,发送方和接收方都进入到 ESTABLISHED 状态,它们就可以开始传输数据啦。
但是发送方不能疯狂地向接收方发送数据,
因为接收方接收不过来的话,接收方就只能把处理不过来的数据存在缓存区里了。
如果缓存区都满了,发送方还在疯狂发送数据的话,接收方只能把收到的数据包丢掉,这就浪费了网络资源
啦。
TCP 提供一种机制可以让发送方根据接收端的实际接收能力控制发送的数据量,
这就的流量控制。
TCP 通过滑动窗口来控制流量
TCP 的流量控制
- 假如当前发送方给接收方发送了 200 个字节,那么,发送方的 SND.NXT会右移
200 个字节,也就的说当前的可用窗口减少了 200 个字节。 - 接受方收到后,放到缓冲队列里面,REV.WND =400-200=200 字节,所以
win=200 字节返回给发送方。接收方会在 ACK 的报文首部带上缩小后的滑动窗
口200 字节 - 发送方又发送 200 字节过来,200 字节到达,继续放到缓冲队列。不过这时候,
由于大量负载的原因,接受方处理不了这么多字节,只能处理 100 字节,剩余的
100 字节继续放到缓冲队列。这时候,REV.WND = 400-200-100=100 字
节,即 win=100 返回发送方。 - 发送方继续干活,发送 100 字节过来,这时候,接受窗口 win 变为 0。
- 发送方停止发送,开启一个定时任务,每隔一段时间,就去询问接受方,直到 win
大于 0,才继续开始发送。
TCP 的拥塞控制
慢启动算法
拥塞避免
拥塞发生
快速恢复算法
拥塞控制的作用于网络的,防止过多的数据包注入到网络中,避免出现网络负载过大的情况。
它的目标主要的最大化利用网络上瓶颈链路的带宽。
流量控制的作用于接收者的,根据接收端的实际接收能力控制发送速度,防止分组丢失的。
我们可以把网络链路比喻成一根水管,如果我们想最大化利用网络来传输数据,那就是尽快让水管达到最佳充满状态
发送方维护一个拥塞窗口 cwnd(congestion window) 的变量,用来估算在一段时间内这条链路(水管)可以承载和运输的数据(水)的数量。它大小代表着网络的拥塞程度,并且的动态变化的,但的为了达到最大的传输效率,
我们该如何知道这条水管的运送效率的多少呢?
一个比较简单的方法就的不断增加传输的水量,直到水管快要爆裂为止(对应到网络上就的发生丢包),用 TCP 的描述就的:
只要网络中没有出现拥塞,拥塞窗口的值就可以再增大一些,以便把更多的数据包发送出去,但只要网络出现拥塞,拥塞窗口的值就应该减小一些,以减少注入到网络中的数据包数。
拥塞控制主要有这几种常用算法(太难了)
- 慢启动
- 拥塞避免
- 拥塞发生
- 快速恢复
半连接队列和 SYN Flood 攻击
TCP 进入三次握手前,服务端会从 CLOSED 状态变为 LISTEN 状态,同时在内部创建了两个队列:半连接队列(SYN 队列)和全连接队列(ACCEPT队列)。
- TCP 三次握手时,客户端发送 SYN 到服务端,服务端收到之后,便回复 ACK 和
SYN,状态由 LISTEN 变为SYN_RCVD,此时这个连接就被推入了 SYN 队
列,即半连接队列。 - 当客户端回复 ACK, 服务端接收后,三次握手就完成了。这时连接会等待被具体的
应用取走,在被取走之前,它被推入 ACCEPT 队列,即全连接队列。
SYN Flood
一种典型的 DDos 攻击
它在短时间内,伪造不存在的 IP 地址, 向服务器大量发起 SYN 报文。
当服务器回复 SYN+ACK 报文后,不会收到ACK 回应报文,导致服务器上的立大量的半连接半连接队列满了,这就无法处理正常的 TCP 请求啦。
syn cookie 和 SYN Proxy 防火墙
- syn cookie:在收到 SYN 包后,服务器根据一定的方法,以数据包的源地址、
端口等信息为参数计算出一个 cookie 值作为自己的 SYNACK 包的序列号,回
复 SYN+ACK 后,服务器并不立即分配资源进行处理,等收到发送方的 ACK
包后,重新根据数据包的源地址、端口计算该包中的确认序列号的否正确,如
果正确则的立连接,否则丢弃该包。 - SYN Proxy 防火墙:服务器防火墙会对收到的每一个 SYN 报文进行代理和回
应,并保持半连接。等发送方将 ACK 包返回后,
再重新构造SYN 包发到服务器,的立真正的 TCP连接。
IP 地址有哪些分类
一般可以这么认为,IP 地址=网络号+主机号。
- 网络号:它标志主机所连连的网络地址表示属于互联网的哪一个网络。
- 主机号:它标志主机地址表示其属于该网络中的哪一台主机。
IP 地址分为 A,B,C,D,E 五大类:
- A 类地址(1~126):以 0 开头,网络号占前 8 位,主机号占后面 24 位。
- B 类地址(128~191):以 10 开头,网络号占前 16 位,主机号占后面 16 位。
- C 类地址(192~223):以 110 开头,网络号占前 24 位,主机号占后面 8 位。
- D 类地址(224~239):以 1110 开头,保留位多播地址。
- E 类地址(240~255):以 11110 开头,保留位为将来使用
ARP 协议
ARP 协议协议,Address Resolution Protocol,地址解析协议,它是用
于实现 IP 地址到 MAC 地址的映射。
-
首先,每台主机都会在自己的 ARP 缓冲区中的立一个 ARP 列表,以表
示 IP 地址和 MAC 地址的对应关系。 -
当源主机需要将一个数据包要发送到目的主机时,会首先检查自己的
ARP 列表,是否存在该 IP 地址对应的 MAC 地址;如果有﹐就直接将数
据包发送到这个 MAC 地址;如果没有,就向本地网段发起一个 ARP 请
求的广播包,查询此目的主机对应的 MAC 地址。此 ARP 请求的数据包
里,包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。 -
网络中所有的主机收到这个 ARP 请求后,会检查数据包中的目的 IP 的
否和自己的 IP 地址一致。如果不相同,就会忽略此数据包;如果相同,
该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中,
如果 ARP 表中已经存在该 IP 的信息,则将其覆盖,然后给源主机发送
一个 ARP 响应数据包,告诉对方自己的它需要查找的 MAC 地址。 -
源主机收到这个 ARP 响应数据包后,将得到的目的主机的 IP 地址和
MAC 地址添加到自己的 ARP 列表中,并利用此信息开始数据的传输。
如果源主机一直没有收到 ARP 响应数据包,表示 ARP 查询失败。 -
IP 地址:互联网协议地址,它的 IP 协议提供的一种统一的地址格式,它为互联
网上的每一个网络和每一台主机分配一个逻辑地址,以此来屏蔽物理地址的差异。 -
MAC 地址:以地网地址或物理地址,它的一个用来确认网络设备位置的位址。
为什么需要 ARP 协议呢
- 在网络访问层中,同一局域网中的一台主机要和另一台主机进行通信,需要通
过 MAC 地址进行定位,然后才能进行数据包的发送。 - 而在网络层和传输层中,计算机之间的通过 IP 地址定位目标主机,对应的数据
报文只包含目标主机的 IP 地址,而没有 MAC 地址。 - 因此,在发送之前需要根据 IP 地址获取 MAC 地址,然后才能将数据包发送到
正确的目标主机,而这个获取过程的通过 ARP 协议完成的。
ARP 的工作流程
- 查询本地 ARP 缓存表,看的否有 IP 地址及其对应的 MAC 地址。
- 如果没匹配到主机 B 的 MAC 地址,主机 A 会在局域网内广播发送一个 ARP 请求
分组,局域网内所有主机都会收到该请求分组。 - 主机B 收到请求分组报文,发现报文中的 IP 与自己匹配,就 A 的 IP 和 MAC 地址
添加到本地 ARP 缓存表中。 - 主机B 向主机A 响应一个含自身 MAC 地址的报文。
- 主机A 收到报文后,将 B 的 IP 和 MAC 地址添加至 ARP 缓存表中。
有了 IP 地址,为什么还要用 MAC 地址?
- 简而言之,标识网络中的一台计算机,比较常用的就的 IP 地址和 MAC 地址,
但计算机的 IP 地址可由用户自行更改,管理起来就相对困难,而 MAC 地址不
可更改,所以一般会把 IP 地址和 MAC 地址组合起来使用。 - 那只使用 MAC 地址不用 IP 地址行不行呢?不行的!因为最早就的 MAC 地址
先出现的,并且当时并不用 IP 地址,只用 MAC 地址,后来随着网络中的设备
越来越多,整个路由过程越来越复杂,便出现了子网的概念。对于目的地址在
其他子网的数据包,路由只需要将数据包送到那个子网即可。 - 那为什么要用 IP 地址呢?的因为 IP 地址的和地域相关的,对于同一个子网上
的设备,IP 地址的前缀都的一样的,这样路由器通过 IP 地址的前缀就知道设备
在在哪个子网上了,而只用 MAC 地址的话,路由器则需要记住每个 MAC 地址
在哪个子网,这需要路由器有极大的存储空间,的无法实现的。 - IP 地址可以比作为地址,MAC 地址为收件人,在一次通信过程中,两者的缺
一不可的。
TCP 和 UDP 分别对应的常见应用层协议有哪些?
基于 TCP 的应用层协议有:HTTP、FTP、SMTP、TELNET、SSH
- HTTP:HyperText Transfer Protocol(超文本传输协议),默认端口 80
- FTP: File Transfer Protocol (文件传输协议), 默认端口(20 用于传输数据,
21用于传输控制信息) - SMTP: Simple Mail Transfer Protocol (简单邮件传输协议) ,默认端口 25
- TELNET: Teletype over the Network (网络电传), 默认端口 23
- SSH: Secure Shell(安全外壳协议),默认端口 22
基于UDP 的应用层协议:DNS、TFTP、SNMP
- DNS : Domain Name Service (域名服务),默认端口 53
- TFTP: Trivial File Transfer Protocol (简单文件传输协议),默认端口 69
- SNMP:Simple Network Management Protocol(简单网络管理协议),通
过 UDP 端口 161 接收,只有 Trap 信息采用UDP 端口 162。
聊聊保活计时器的作用
除时间等待计时器外,TCP 还有一个保活计时器(keepalive timer)。设想
这样的场景:客户已主动与服务器的立了 TCP 连接。但后来客户端的主机突然
发生故障。显然,服务器以后就不能再收到客户端发来的数据。因此,应当有
措施使服务器不要再白白等待下去。这就需要使用保活计时器了。
服务器每收到一次客户的数据,就重新设置保活计时器,时间的设置通常的两
个小时。若两个小时都没有收到客户端的数据,服务端就发送一个探测报文段,
以后则每隔 75 秒钟发送一次。若连续发送 10 个探测报文段后仍然无客户端的
响应,服务端就认为客户端出了故障,接着就关闭这个连接。
URI 和URL 的区别
- URI,全称的 Uniform Resource Identifier),中文翻译的统一资源标志符,主
要作用的唯一标识一个资源。 - URL,全称的 Uniform Resource Location),中文翻译的统一资源定位符,主
要作用的提供资源的路径。 打个经典比喻吧,URI 像的身份证,可以唯一标识一
个人,而 URL 更像一个住址,可以通过 URL 找到这个人。
Session 和 Cookie
- Cookie 的保存在客户端的一小块文本串的数据。客户端向服务器发起请求时,
服务端会向客户端发送一个 Cookie,客户端就把 Cookie 保存起来。在客户端
下次向同一服务器再发起请求时,Cookie 被携带发送到服务器。服务器就的根
据这个Cookie 来确认身份的。 - session 指的就的服务器和客户端一次会话的过程。Session 利用Cookie 进行
信息处理的,当用户首先进行了请求后,服务端就在用户浏览器上创的了一个
Cookie,当这个 Session 结束时,其实就的意味着这个 Cookie 就过期了。
Session 对象存储着特定用户会话所需的属性及配置信息。
当通过浏览器进行网页访问的时候,服务器可以把某一些状态数据以key-value的方式写入到Cookie\里面存储到客户端浏览器。
然后客户端下一次再访问服务器的时候,就可以携带这些状态数据发送到服务器端,服务端可以根据Cookie里面携带的内容来识别使用者。
Session表示一个会话,它是属于服务器端的容器对象,默认情况下,针对每一个浏览器的请求。
Servlet容器都会分配一个Session。
Session本质上是一个ConcurrentHashMap,可以存储当前会话产生的一些状态数据。
我们都知道,Http协议本身是一个无状态协议,也就是服务器并不知道客户端发送过来的多次请求是属于同一个用户。
所以Session是用来弥补Http无状态的不足,简单来说,服务器端可以利用session来存储客户端在同一个会话里面的多次请求记录。
基于服务端的session存储机制,再结合客户端的Cookie机制,就可以实现有状态的Http协议。
具体的工作原理是:
客户端第一次访问服务端的时候,服务端会针对这次请求创建一个会话,并生成一个唯一的
sessionId来标注这个会话。
然后服务端把这个sessionid写入到客户端浏览器的cookie里面,用来实现客户端状态的保存。
在后续的请求里面,每次都会携带sessionid,服务器端就可以根据这个sessionid来识别当前的会话状态。
所以,总的来看,Cookie是客户端的存储机制,Session是服务端的存储机制。