七层体系结构(OSI七层结构) :为了使全世界不同体系结构的计算机能够互联,国际化标准组织ISO提出开放系统互联基本参考模型,简称OSI,即所谓的7层协议体系结构。
TCP/IP四层模型 :是由实际应用发展总结出来的,它包含了应用层、传输层、网际层和网络接口层
五层体系结构 :五层模型只出现在计算机网络学习教学过程中,他是对七层模型和四层模型的一个折中,及综合了OSI和TCP/IP 体系结构的优点,这样既简洁又能将概念阐述清楚,(主要是因为官方的7层模型太过麻烦复杂)因此主要差别是去掉了会话层和表示层,而传输层改为了运输层,因为他们觉得运输名字更贴切。
Http在哪一层?tcp/udp在哪一层?ip在哪一层?你还能说出哪些协议?
各层功能
应用层
- 与其它计算机进行通讯的一个应用,它是对应应用程序的通信服务的。例如,一个没有通信功能的字处理程序就不能执行通信的代码,从事字处理工作的程序员也不关心OSI的第7层。但是,如果添加了一个传输文件的选项,那么字处理器的程序就需要实现OSI的第7层。示例:TELNET,HTTP,FTP,NFS,SMTP等。
表示层
- 这一层的主要功能是定义数据格式及加密。例如,FTP允许你选择以二进制或ASCII格式传输。如果选择二进制,那么发送方和接收方不改变文件的内容。如果选择ASCII格式,发送方将把文本从发送方的字符集转换成标准的ASCII后发送数据。在接收方将标准的ASCII转换成接收方计算机的字符集。示例:加密,ASCII等。
会话层
- 它定义了如何开始、控制和结束一个会话,包括对多个双向消息的控制和管理,以便在只完成连续消息的一部分时可以通知应用,从而使表示层看到的数据是连续的,在某些情况下,如果表示层收到了所有的数据,则用数据代表表示层。示例:RPC,SQL等。
传输层
- 这层的功能包括是选择差错恢复协议还是无差错恢复协议,及在同一主机上对不同应用的数据流的输入进行复用,还包括对收到的顺序不对的数据包的重新排序功能。示例:TCP,UDP,SPX。
网络层
- 这层对端到端的包传输进行定义,它定义了能够标识所有结点的逻辑地址,还定义了路由实现的方式和学习的方式。为了适应最大传输单元长度小于包长度的传输介质,网络层还定义了如何将一个包分解成更小的包的分段方法。示例:IP,IPX等。
数据链路层
- 它定义了在单个链路上如何传输数据。这些协议与被讨论的各种介质有关。示例:ATM,FDDI等。
物理层
- OSI的物理层规范是有关传输介质的特性,这些规范通常也参考了其他组织制定的标准。连接头、帧、帧的使用、电流、编码及光调制等都属于各种物理层规范中的内容。物理层常用多个规范完成对所有细节的定义。示例:Rj45,802.3等。
对应协议 | |
应用层 | http 超文本传输协议 smtp 电子邮件协议 ftp 文件传输协议 telnet 远程登陆协议 dns域名系统 |
表示层 | LPP、NBSSP |
会话层 | SSL、TLS、DAP、LDAP |
传输层 | tcp ,udp |
网络层 | ip |
数据链路层 | 以太网、网卡、交换机、PPTP、L2TP、ARP、ATMP |
物理层 | 物理线路、光纤、中继器、集线器,双絞线(传输bite) |
即http在应用层,tcp/udp在运输层(传输层),ip在网络层,各个层还有很多其他协议。
TCP/UDP
TCP:传输控制协议 TCP(Transmission Control Protocol),TCP 提供面向连接的服务,在传送数据之前必须先建立连接,数据传送结束后要释放连接。
UDP:用户数据报协议 UDP(User Datagram Protocol),UDP 在传送数据之前不需要先建立连接,远程主机在收到 UDP 报文后,不需要给出任何确认。
TCP 的三次握手和四次挥手
三次握手过程:
- 第一次握手 :客户端向服务端发送一个SYN 报文(SYN = 1),并指明客户端的初始化序列号 ISN(x),初始序号x不是1,而是一个随机数。
- 第二次握手 :服务器收到客户端的 SYN 报文之后,会发送 SYN 报文作为应答(SYN = 1),并且指定自己的初始化序列号 ISN(y),ACK=1表示对客户端发送报文的确认,同时会把客户端的 x + 1 作为确认号 ack 的值,表示已经收到了客户端发来的的 SYN 报文,希望收到的下一个数据的第一个字节的序号是 x + 1 之后的字节数据。
- 第三次握手 :客户端收到服务器端响应的 SYN 报文之后,会发送一个 ACK 报文,也是一样把服务器的 y + 1 作为 ack 的值,表示已经收到了服务端发来的的 SYN 报文,希望收到的下一个数据的第一个字节的序号是 y + 1 之后的数据。seq=x+1 说明该报文携带的数据是x+1之后的字节数据,此时客户端处于 Establised 状态。
服务端收到ack之后也处于 Establised 状态,双方就建立起了 TCP 连接。
为什么双方建立连接需要三次握手而不是两次或者四次握手?
三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的,
四次握手:主要就是目前三次握手中的第二次握手时,先响应ACK给客户端,然后再发送服务端的SYN给客户端,这两次完全可以合并成一次握手。
三次能完成的东西,四次就已经没有意义了,这里主要解释为什么两次不行。
原因一:避免历史连接
假如是两次握手,那么第一次握手:客服端向服务端发送链接请求,第二次握手:服务端收到请求后响应报文,此时服务端处于Establised 状态,客服端收到应答后也处于Establised 状态,至此建立链接。
这样看起来没什么问题,但是实际网络情况是非常复杂的,假如第一次握手时,客服端向服务端发送连接请求,请求因为网络延迟,服务端一直无法收到请求,客服端等待超时后,又发了一次建立连接请求,然而,前一次的连接请求先到达了服务端,服务端因为是被动响应,它只能响应给客户端,建立连接,结果新的连接请求也到达了服务端,它又建立了一次连接。导致服务端建立一个历史的无用连接,造成了资源浪费。
原因二:同步双方初始序列号接
TCP 协议的通信双方, 都必须维护一个「序列号」, 序列号是可靠传输的一个关键因素,它的作用是:
接收方可以去除重复的数据
接收方可以根据数据包的序列号按序接收
可以标识发送出去的数据包中, 哪些是已经被对方收到的
序列号在 TCP 连接中占据着非常重要的作用,所以当客户端发送携带「初始序列号」的 SYN 报文的时候,需要服务端回一个 ACK 应答报文,表示客户端的 SYN 报文已被服务端成功接收,那当服务端发送「初始序列号」给客户端的时候,依然也要得到客户端的应答回应,这样一来一回,才能确保双方的初始序列号能被可靠的同步
如果只有两次握手,它只保证了一方的初始序列号能被对方成功接收,没办法保证双方的初始序列号都能被确认接收。
四次挥手过程
- 第一次挥手 :客户端发送一个 FIN 报文(请求连接终止:FIN = 1),报文中会指定一个序列号 seq = u。并停止再发送数据,主动关闭 TCP 连接。此时客户端处于 FIN_WAIT1 状态,等待服务端的确认。
- 第二次挥手 :服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序号值 +1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT 状态。客户端收到服务端的确认后,进入FIN_WAIT2(终止等待 2)状态,等待服务端发出的连接释放报文段。而此时服务端可能还有数据没接收完,这次挥手只是告诉客户端你可以关闭了,我还要再等等。这个时候客户端处于半关闭状态,它不会主动发送报文,但是如果服务端要求重放某个报文,它会继续重发等。
- 第三次挥手 :服务端把各种报文数据都处理完了,它也想关闭这个连接,此时它会发送一个 FIN=1,ACK=1,seq=w,ack=u+1 的报文
- 第四次挥手 :客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答(ack = w+1),且把服务端的序列值 +1 作为自己 ACK 报文的序号值(seq=u+1),此时客户端处于 TIME_WAIT (时间等待)状态。这个时候由服务端到客户端的 TCP 连接并未释放掉,需要经过时间等待计时器设置的时间 2MSL(一个报文的来回时间) 后才会进入 CLOSED 状态(这样做的目的是确保服务端收到自己的 ACK 报文。如果服务端在规定时间内没有收到客户端发来的 ACK 报文的话,服务端会重新发送 FIN 报文给客户端,客户端再次收到 FIN 报文之后,就知道之前的 ACK 报文丢失了,然后再次发送 ACK 报文给服务端)。服务端收到 ACK 报文之后,就关闭连接了,处于 CLOSED 状态。
为什么要四次挥手
关闭连接时,客户端向服务端发送 FIN 时,仅仅表示客户端不再发送数据了但是还能接收数据,服务端收到客户端的 FIN 报文时,先回一个 ACK 应答报文,而服务端可能还有数据需要处理和发送的数据,等服务端不再发送数据时,才发送 FIN 报文给客户端来表示同意现在关闭连接。因此是需要四次挥手。
UDP介绍、为什么是不可靠的
UDP头部报文只有8个字节:
- 源端口和目标端口,与TCP类似,标识即该数据包由谁发送,由谁接收
- 包长度:UDP头部长度+数据长度
- 校验和:伪头部,头部,数据 三部分的校验和,伪头部并非UDP报文中的有效数据,是提取了IP数据报中的源IP,目的IP信息并加上协议等字段构造的数据。伪头部在实际网络传输中,仅用作校验和计算使用,并不发送!因此称为伪头部。
UDP的特点:
- 不建立连接:减少了三次握手的耗时,也就不需要维护连接状态,包括收发状态等
- 不保证可靠交付:报文可能丢失、乱序,而且不负责重发。丢失时可以通知应用层,让应用层组织重发。因为不保证可靠交付,所以也没有确认应答机制
- 面向报文:发送方的UDP对应用程序交下来的报文, 在添加首部后就向下交付给IP层。既不拆分,也不合并,而是保留这些报文的边界, 因此需要应用层决定一次发送多少数据以避免发生IP分片。
- 首部开销小:相比TCP首部的20个字节,它只有8个字节;
- 没有拥塞控制:网络出现拥塞时也不限制发送端的发送速率,这意味着发送速率稳定,但发生拥塞时会因为路由器缓存溢出而丢失分组,而且不限速的发送也会导致拥塞和加重拥塞
- 因为它不建立连接,也不确认报文,也就无法保证传输的可靠性。
UDP常用于即时通信(QQ聊天 对数据准确性和丢包要求比较低,但速度必须快),在线视频(RTSP 速度一定要快,保证视频连续,但是偶尔花了一个图像帧,人们还是能接受的),网络语音电话(VoIP 语音数据包一般比较小,需要高速发送,偶尔断音或串音也没有问题)等等。
TCP 协议有哪些缺陷?
TCP协议存在的问题:
- 升级 TCP 的工作很困难:TCP 协议是在内核中实现的,应用程序只能使用不能修改,如果要想升级 TCP 协议,那么只能升级内核,然而服务器的内核升级比较保守和缓慢。很多 TCP 协议的新特性,都是需要客户端和服务端同时支持才能生效的,任意一方没有升级,我们可能就无法享受TCP的新特性。所以即使 TCP 有比较好的特性更新,也很难快速推广,用户往往要几年或者十年才能体验到。
- TCP 建立连接的延迟:基于 TCP 实现的应用协议,都是需要先建立三次握手才能进行数据传输,比如 HTTP 1.0/1.1、HTTP/2、HTTPS,现在大多数网站都是使用 HTTPS 的,这意味着在 TCP 三次握手之后,还需要经过 TLS 四次握手后,才能进行 HTTP 数据的传输,这在一定程序上增加了数据传输的延迟
- TCP 存在队头阻塞问题:TCP 是字节流协议,TCP 层必须保证收到的字节数据是完整且有序的,如果序列号较低的 TCP 段在网络传输中丢失了,即使序列号较高的 TCP 段已经被接收了,应用层也无法从内核中读取到这部分数据,必须要等待重传。
- 网络迁移需要重新建立 TCP 连接:基于 TCP 传输协议的 HTTP 协议,由于是通过四元组(源 IP、源端口、目的 IP、目的端口)确定一条 TCP 连接。那么当移动设备的网络从 4G 切换到 WIFI 时,意味着 IP 地址变化了,那么就必须要断开连接,然后重新建立 TCP 连接。而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延,以及 TCP 慢启动的减速过程,给用户的感觉就是网络突然卡顿了一下,因此连接的迁移成本是很高的。
http
1. http是什么?
HTTP 是超文本传输协议,更准确的说:HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」
HTTP 协议中的数据是明文传输的,任何中间人(man-in-the-middle)都可以读取传输的数据,因此 HTTP 是一种不安全的协议。
2. http常见状态码有哪些?
记住下面这张图就够了
GET,POST区别
GET:从服务器获取资源,参数放在URL中,HTTP协议规范没有对URL长度进行限制,GET请求参数实际没有长度限制,所谓的请求长度限制是由浏览器和web服务器决定和设置的。请求具有幂等性,即访问一次和N次的效果都是一样的,它对服务器没有提交数据,所以不会影响服务器的数据。
POST:向服务器提交数据,参数放在请求体里。请求不具有幂等性
GET和POST只是HTTP请求的方式,http又是基于 TCP 传输协议进行通信的,那么底层都是TCP,TCP是没有GET和POST区分的,所以本质上GET和POST是没有区别的。就像上面关于GET和POST的描述,如果程序员就拿GET做提交也不是不可以,或者用POST做数据查询也无不可。
https是什么
上面说到http是一种不安全的协议,那么HTTPS 就是解决 HTTP 不安全的缺陷,在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议,使得报文能够加密传输(HTTPS 协议自身不能加密数据,它需要借助SSL/TLS 安全协议加密)。
SSL协议:SSL 协议由 Netscape 团队设计,于1995年发布 SSL 2.0版本,之后发布了 SSL 3.0版本,IETF 已于2015年不推荐使用 SSL 3.0。 目前,TLS 协议已经替代了 SSL 协议,SSL 协议已不再使用。
TLS协议:是旨在提供安全通信的加密协议,使用 TLS 可以加密与服务器的所有通信。当前使用最广的是 TLS1.2、TLS1.3
https是如何建立连接的
http协议只需要TCP的三次握手后就可以进行传输了,而https在tcp与http之间又加了一层TLS协议,当前使用最广的是 TLS1.2、TLS1.3。
使用TLS1.2 协议时(以ECDHE算法为例)需要4次握手交换双方的密钥:
- 第一次握手:客户端首先会发一个Client Hello 消息,消息里面有客户端使用的 TLS 版本号、支持的密码套件列表,以及生成的随机数;
- 第二次握手:服务端收到消息后,响应Server Hello消息,消息内包含选取的协议版本、加密方法,服务端证书,服务端随机数等;
- 第三次握手:客户端收到了服务端的证书后,校验合法性,算好会话密钥并告知服务端后续改用对称算法加密通信,并发送Finished 消息;
- 第四次握手:服务端收到后,也通知客户端后续数据会加密传输,验证客户端的 Finished 消息并完成 TLS 握手;
使用TLS1.3 协议时需要2次握手:
- 客户端向服务端发送ClientHello消息,消息包含协议版本、客户端随机数和密码套件列表(密码套件要比TLS1.2少很多)、用于计算预主密钥的参数(客户端假设它知道服务器的首选密钥交换方法)、随机数等;
- 服务端收到消息后,创建主密钥,并响应服务器证书、数字签名、服务器随机数以及完成消息;客服端收到服务端信息后,验证并完成;至此两次握手就完成了TLS连接过程。