计算机网络知识

OSI参考模型

OSI(参考模型)将通讯功能划分为7个分层,称做OSI参考模型。OSI协议以OSI参考模型为基础界定了每一个阶层之间接口相关的标准。css

OSI参考模型中各个分层的做用

分层名称 功能 功能概览
应用层 为应用程序提供服务并规定应用程序中通讯相关的细节。 电子邮件协议、远程登陆协议、文件传输协议
表示层 设备固有数据格式和网络标准数据格式的转换。将应用处理的信息转换为适合网络传输的格式,或未来自下一层数据转换成为上层可以处理的格式。所以它主要负责数据格式的转换。 接受不一样表现形式的信息,如文字流、图像、声音等
会话层 通讯管理。负责创建和断开通讯链接(数据流动的逻辑通路),以及数据的分割等数据传输相关的管理,管理传输层如下的分层 什么时候创建链接,什么时候断开链接以及保持多久的链接
传输层 管理两个节点之间的数据传输。负责可靠传输(确保数据被可靠地传送到目标地址) ,只在通讯双方节点上进行处理,而无需在路由器上处理。 是否有数据丢失
网络层 将数据传输到目标地址。目标地址能够是多个网络经过路由器链接而成的某一个地址。所以这一层主要负责地址管理与路由选择 通过哪一个路由传递到目标地址
数据链路层 负责物理层面上互连的、节点之间的通讯传输。例如与1个以太网相连的2个节点之间的通讯。互连设备之间传送和识别数据帧 数据帧与比特流之间的转换,将0、1序列划分为具备意义的数据帧传送给对端(数据帧的生成与接收)
物理层 负责0、1比特流(0、1序列)与电压的高低、光的闪灭之间的互换。界定链接器和网线的规格。 比特流与电子信号之间的切换

OSI模块化通讯传输

通讯与7个分层:
微信图片_20200520131834.jpghtml

发送方从第7层到第6层最后到第1层由上至下按照顺序传输数据,而接收端则从第1层开始由下至上向每一个上一级分层传输数据。
每一个分层上,在处理由上一层传过来的数据时能够附上当前分层的协议所必须的“首部”信息。而后接受端对收到的数据进行数据“首部”与“内容”的分离,再转发给上一层,并最终将发送端的数据恢复为原状。
  • 应用层的工做
    从用户输入完成所要发送的内容并点击“发送”按钮的那一刻开始,就进入了应用层协议的处理。该协议会在所要传输数据的前端附加一个首部(标签)信息。该首部标明了邮件内容“早上好”和收件人为“B”。这一附有首部信息的数据传送给主机B 之后由该主机上的收发邮件软件经过“收信”功能获取内容。
    主机B上的应用收到主机A发送过来的数据后,分析其数据首部与数据正文,并将邮件保存到硬盘或者是其余非易失性存储器以备进行相应的处理。若是主机B上收件人的邮箱空间已满没法接收新的邮件,则会返回一个错误给发送方。对这类异常的处理也正属于应用层须要解决的问题。
  • 表示层的工做
    将数据从“某个计算机特定的数据格式”转换为“网络通用的标准数据格式”后再发出去。接受端主机收到数据之后将这些网络标准格式的数据恢复为“该计算机特定的数据格式”,而后再进行相应的处理。因为数据被转换成为了通用标准的格式再进行处理,使得异构的机型之间也能保持数据的一致性。这也正是表示层的做用所在。即表示层是进行“统一的网络数据格式”与“某一台计算机或某一款软件特有的数据格式”之间互相转换的分层。
    表示层(主机A)与表示层(主机B)之间为了识别编码的格式也会附加首部信息,从而将实际传输的数据转交给下一层去处理。
  • 会话层的工做
    假定用户A新建了5封邮件准备发送给用户B。这5封邮件的发送顺序能够有不少种。例如,能够每发一封邮件时创建一次链接(通讯链接),随后断开链接。还能够一经创建好链接后就将5封邮件连续发送给对方。决定采用何种链接方法是会话层的主要责任。
    会话层也像应用层或表示层那样,在其收到的数据前端附加首部或标签信息后再转发给下一层。而这些首部或标签中记录着数据传送顺序的信息。
以上说明了在应用层写入数据经由表示层格式化编码、再由会话层标记发送顺序后才被发送出去的大体过程。然而会话层只对什么时候创建链接、什么时候发送数据等问题进行管理(定时间),并不具备实际传输数据的功能。真正负责在网络上传输具体数据的是会话层如下的。
  • 传输层的工做
    进行创建链接或者断开链接的处理,在两个主机之间建立逻辑上的通讯链接便是传输层的主要做用。此外,传输层为确保所传输的数据到达目标地址,会在通讯两端的计算机之间进行确认,若是数据没有到达,它会负责进行重发
    例如,主机A将“早上好”这一数据发送给主机B。期间可能会由于某些缘由致使数据被破坏,或因为发生的某些网络异常致使只有一部分数据到达目标地址。假设主机B只收到了“早上”这一部分,那么它会在收到数据后将本身没有收到“早上”以后那部分数据的事实告知主机A。主机A得知这个状况后就会将后面的“好”重发给主机B,并再次确认对端是否收到。
保证数据传输的可靠性是传输层的一个重要做用。为了确保可靠性,在这一层也会为所要传输的数据附加首部以识别这一分层的数据。然而,实际上将数据传输给对端的处理是由网络层来完成的。
  • 网络层的工做
    网络层的做用是在网络与网络互相链接的环境中,将数据从发送端主机发送到接受端主机。两端主机之间虽然有众多数据链路,但可以将数据从主机A送到主机B也都是网络层的功劳。
    在实际发送数据时,目的地址相当重要。这个地址是进行通讯的网络中惟一指定的序号。也能够把它想象成为平常生活中的电话号码。只要这个目标地址肯定了,就能够在众多计算机中选出该目标地址所对应的计算机发送数据。基于这个地址,就能够在网络层进行数据包的发送处理。而有了地址和网络层的包发送处理,就能够将数据发送到世界上任何一台互连设备。网络层中也会将其从上层收到的数据和地址信息等一块儿发送给下面的数据链路层,进行后面的处理。
传输层与网络层的关系
在不一样的网络体系下,网络层又是也不能保证数据的可达性。例如,在至关于TCP/IP网络层的IP协议中,就不能保证数据必定会发送到对端地址。所以,数据传送过程当中出现数据丢失、顺序混乱等问题可能性会大大增长。像这样没有可靠性传输要求的网络层中,能够由传输层负责提供“正确传输数据的处理”。TCP/IP中,网络层与传输层相互协做以保证数据包可以传送到 世界各地,实现可靠传输。
  • 数据链路层、物理层
    通讯传输实际上就是经过物理的传输介质实现的。数据链路层的做用就是在这些经过传输介质互连的设备之间进行数据处理
    物理层中,将数据0、1转换为电压和脉冲光传输给物理的传输介质,而相互直连的设备之间使用地址实现传输。这种地址被称为MAC地址(Media Access Control,介质访问控制),也可称为物理地址或硬件地址。采用MAC地址,目的是为了识别链接到同一个传输介质上的设备。所以在这一分层中将包含MAC地址信息的首部附加到从网络层转发过来的数据上,将其发送到网络。
网络层与数据链路层都是基于目标地址将数据发送给接受端的,可是网络层负责将整个数据发送给最终目标地址,而数据链路层则只负责一个分段内的数据。
微信图片_20200520190537.jpg

TCP和UDP

TCP/IP中有两个具备表明性的传输层协议,分别是TCP和UDP前端

TCP

TCP是面向链接的、可靠的流协议。流就是指不间断的数据结构,你能够把它想象成排水管道中的水流。当应用程序采用TCP发送消息时,虽然能够保证发送的顺序,但仍是犹如没有任何间隔的数据流发送给接收端。为提供可靠性传输,实行“顺序控制”或“重发控制”机制。
微信图片_20200521144103.jpg
TCP首部包括:linux

  • 源端口号和目标端口号(用以识别发送主机跟接收主机上的应用)
  • 序列号(用以表示该包中数据是发送端整个数据中第几字节的序列号)
  • 确认应答号(下一次应该收到的数据的序列号,已收到确认应答号前一位为止的数据,发送端收到这个确认应答之后能够认为这个序号之前的数据已经被正常接收)
  • 校验和(用以判断数据是否被损坏)
  • 数据偏移(表示TCP所传输的数据部分应该从TCP包的哪一个位开始计算,也能够把它当作TCP首部的长度)
  • 控制位(字段长8位,包括ACK(值为1,确认字段应答变为有效)SYN(为1表示但愿创建链接,并在其序列号字段进行序列初始值的设定)FIN(为1时表示从此不会发送数据,但愿断开链接,每一个主机对对方的FIN包进行确认后就能够断开链接))

经过序列号和确认号应答(ACK)TCP实现可靠性传输算法

UDP

UDP是无链接(发送报文段前,通讯双方没有握手的过程)的,不具备可靠性的数据报协议。细微的处理它会交给上层的应用去完成。在UDP的状况下,虽然能够确保发送消息的大小,却不能保证消息必定会到达。所以,应用有时候会根据本身的须要进行重发处理。
微信图片_20200521144110.jpg
UDP首部包括:数据库

  • 源端口号和目标端口号
  • 包长度(保存了UDP首部的长度跟数据的长度之和)
  • 校验和(UDP差错校验机制可是没有差错恢复能力)
(TCP/IP中识别一个进行通讯的应用须要5大元素,“源IP地址”、“目标IP地址”、“源端口”、“目标端口”、“协议号”,然而UDP的首部中只包含它们当中的两项“源端口和目标端口”,剩下的3项都包含在IP首部里,若是这3项被破坏了可能致使收包应用收不到包,或者不应收到的应用收到了,因此有必要验证通讯中5项识别码是否正确,引入伪首部,`TCP/UDP经过伪首部,得以对5项数字进行验证,从而实现即便在IP首部并不可靠地状况下仍然可以提供可靠传输`)

TCP和UDP区分

  • TCP用于在传输层有必要实现可靠传输的的状况。因为它是面向有链接并具有顺序控制、重发控制等机制,因此它能够为应用提供可靠传输。windows

    • TCP 协议是面向链接的,在通讯双方进行通讯前,须要经过三次握手创建链接。它须要在端系统中维护双方链接的状态信息;
    • TCP 协议经过序号、确认号、定时重传、检验和等机制,来提供可靠的数据传输服务;
    • TCP 协议提供的是点对点的服务,即它是在单个发送方和单个接收方之间的链接;
    • TCP 协议提供的是全双工的服务,也就是说链接的双方的可以向对方发送和接收数据;
    • TCP 提供了拥塞控制机制,在网络拥塞的时候会控制发送数据的速率,有助于减小数据包的丢失和减轻网络中的拥塞程度;
    • TCP 提供了流量控制机制,保证了通讯双方的发送和接收速率相同。若是接收方可接收的缓存很小时,发送方会下降发送 速率,避免由于缓存填满而形成的数据包的丢失
  • UDP主要用于那些对高速传输和实时性有较高要求的通讯或广播通讯。浏览器

    • 由于UDP没有握手的过程因此没有创建链接的时延,没有链接也不须要在端系统中保存链接的状态;
    • UDP提供尽力而为的交付服务,也就是说UDP不保证数据的可靠交付
    • UDP没有拥塞控制和流量控制,因此报文段的发送速率没有限制;
    • 由于UDP套接字只使用目的地址和目的端口来标识,因此能够支持一对1、一对多、多对一和多对多的交互通讯;
    • UDP首部小,只有8个字节。
举例:经过IP电话进行通讯,若是使用TCP,数据在传送途中若是丢失会被重发,但这样没法流畅的传输通话人的声音,会致使没法进行正常交流。而采用UDP,他不会进行重发处理。从而也就不会有声音大幅度延迟到达的问题。即便有部分数据丢失,也只是影响某一部分的通话。此外,在多播(一对多)与广播(一对全体)通讯中,也使用UDP而不是TCP。

包、帧、数据报、段、消息

以上五个术语都是用来表述数据的单位,区分以下:缓存

  • 能够说是全能性术语。
  • 用于表示数据链路层中包的单位。
  • 数据报是IP和UDP等网络层以上的分层中包的单位。
  • 则表示TCP数据流中的信息。
  • 消息是指应用协议中数据的单位。

TCP链接

使用TCP首部用于控制的字段来管理TCP链接。一个链接的创建与断开,至少须要来回发送7个包才能完成。TCP经过检验和、序列号、确认应答、重发机制、链接管理以及窗口控制等机制实现可靠性传输。
微信图片_20200521130619.jpg安全

  • 在TCP中,当发送端的数据到达接收主机时,接收端主机会返回一个已收到消息的通知。这个消息叫作确认应答(ACK)。当发送端将数据发出后会等待对端的确认应答,若是有确认应答,说明数据已经成功到达对端;在必定时间内没有等到确认应答,发送端就会认为数据已经丢失(有多是发送数据丢失或者确认应答消息丢失),从新发送。
  • 若是确认应答由于某些缘由致使应答延迟到达,源主机会重复发出数据,目标主机反复接受相同的数据,而为了对上层应用提供可靠地传输,必须放弃重复的数据包。为此引入一种机制,可以识别是否已经接受数据,又能判断是否须要接收。这些确认应答处理、重发控制以及重复控制等功能都是能够经过序列号实现。
序列号是按顺序给发送数据的每个字节(8位字节)都标上号码的编号。接收端查询接收数据TCP首部中的序列号和数据长度,将本身下一步应该接收的序列号做为确认应答返送回去。就这样,经过序列号和确认应答号,TCP实现可靠性传输。
微信图片_20200521133108.jpg

三次握手

  1. 第一次握手,客户端向服务器发送一个 SYN 链接请求报文段,报文段的首部中 SYN 标志位置为 1,序号字段是一个任选的 随机数。它表明的是客户端数据的初始序号。(客户端调用connect发起主动打开active open),客户端状态SYN_SENT
  2. 第二次握手,服务器端接收到客户端发送的 SYN 链接请求报文段后,服务器首先会为该链接分配 TCP 缓存和变量,而后向 客户端发送 SYN ACK 报文段,报文段的首部中 SYN 和 ACK 标志位都被置为 1,表明这是一个对 SYN 链接请求的确认, 同时序号字段是服务器端产生的一个任选的随机数,它表明的是服务器端数据的初始序号。确认号字段为客户端发送的序号加一。(服务端socket\bind\listen被动打开passive open),接收端状态SYN_RECEIVE
  3. 第三次握手,客户端接收到服务器的确定应答后,它也会为此次 TCP 链接分配缓存和变量,同时向服务器端发送一个对服务 器端的报文段的确认。第三次握手能够在报文段中携带数据。客户端和接收端状态ESTABLISHED

微信图片_20200521135435.jpg

TCP 三次握手的创建链接的过程就是相互确认初始序号的过程,告诉对方,什么样序号的报文段可以被正确接收。 第三次握手的做用是客户端对服务器端的初始序号的确认。若是只使用两次握手,那么服务器就没有办法知道本身的序号是否已被确认。同时这样也是为了防止失效的请求报文段被服务器接收,而出现错误的状况。

四次挥手

由于 TCP 链接是全双工的,也就是说通讯的双方均可以向对方发送和接收消息,因此断开链接须要双方的确认。

  1. 第一次挥手,客户端认为没有数据要再发送给服务器端,它就向服务器发送一个 FIN 报文段,申请断开客户端到服务器端的 链接。发送后客户端进入 FIN\_WAIT\_1 状态
  2. 第二次挥手,服务器端接收到客户端释放链接的请求后,向客户端发送一个确认报文段,表示已经接收到了客户端释放链接的 请求,之后再也不接收客户端发送过来的数据。可是由于链接是全双工的,因此此时,服务器端还能够向客户端发送数据。服务 器端进入 CLOSE\_WAIT 状态。客户端收到确认后,进入 FIN\_WAIT\_2 状态。
  3. 第三次挥手,服务器端发送完全部数据后,向客户端发送 FIN 报文段,申请断开服务器端到客户端的链接。发送后进入 LAS T\_ACK 状态。
  4. 第四次挥手,客户端接收到 FIN 请求后,向服务器端发送一个确认应答,并进入 TIME\_WAIT 阶段。该阶段会持续一段时间, 这个时间为报文段在网络中的最大生存时间,若是该时间内服务端没有重发请求的话,客户端进入 CLOSED 的状态。若是收到 服务器的重发请求就从新发送确认报文段。服务器端收到客户端的确认报文段后就进入 CLOSED 状态,这样全双工的链接就被 释放了。

微信图片_20200521140918.jpg
TCP 使用四次挥手的缘由是由于 TCP 的链接是全双工的,因此须要双方分别释放到对方的链接,单独一方的链接释放,只代 表不能再向对方发送数据,链接处于的是半释放的状态。
最后一次挥手中,客户端会等待一段时间再关闭的缘由,是为了防止发送给服务器的确认报文段丢失或者出错,从而致使服务器 端不能正常关闭。

HTTPS

TLS/SSL和HTTPS

Web中能够经过TSL/SSL对HTTP通讯进行加密。使用TSL/SSL的HTTP通讯叫作HTTPS通讯。HTTPS中采用对称加密方式。而在发送其公共密钥时采用的则是公钥加密方式。
WechatIMG5404.jpeg
确认公钥是否正确主要使用认证中心(CA)签发的证书,而主要的认证中心信息已经嵌入到浏览器出厂设置中。若是Web浏览器中还没有加入某个认证中心,那么会在页面上提示一个警告信息。此时,判断认证中心是否合法与否就要由用户本身决定。

SSL/TLS协议的基本思路是采用公钥加密法;
SSL/TLS协议的基本过程是这样的:
(1) 客户端向服务器端索要并验证公钥。
(2) 双方协商生成”对话密钥”。客户端用公钥对对话秘钥进行加密。
(3) 服务器经过私钥解密出对话秘钥
(3) 双方采用”对话密钥”进行加密通讯。
上面过程的前两步,又称为”握手阶段”

注意:服务器有两个密钥,一个公钥、一个私钥,只有私钥才能够解密公钥加密的消息;

对称加密:加密效率高,速度快,适合大数据量加密。DES/AES

非对称加密:算法复杂,加密速度慢,安全性更高。结合对称加密使用。RSA、DH RSA 算法的可靠性基础:对极大整数作因数分解是很困难的

信息加密技术

单向散列加密

单向散列加密是指经过对不一样输入长度的信息进行散列计算,获得固定长度的输出,这个散列计算过程是单向的,即不能对输出进行计算从而获得输入信息。

WechatIMG149.jpeg

利用散列表这个特性,能够进行密码加密保存,即用户注册时输入的密码不直接保存在数据库中,而是对密码进行单向散列表加密,将密文存入数据库,用户登录时,进行密码验证,一样计算获得输入密码的密文,并和数据库中的密文比较,若是结果一致,则密码验证成功。
具体过程如图:

WechatIMG150.jpeg

这样保存在数据库中的是用户输入的密码的密文,并且是不可逆计算获得的密码的明文,所以即便数据库被“暴露”,也不会泄露用户的密码信息。
另外,虽然不能经过算法将单向散列密文反算获得明文,可是因为人们设置密码具备必定的模式,所以经过彩虹表(人们经常使用的密码与对应的密文关系表,具体我还不了解。。。)等手段进行猜想式破解。(没有绝对的安全~~~)
为了增强单向散列计算的安全性,还会给散列算法加点盐(salt),salt至关于加密的密钥,增长破解的难度。

经常使用的单向散列算法有MD五、SHA等。单向散列算法还有一个特色就是输入的任何微小变化都会致使输出的彻底不一样,这个特性有时也会被用来生成信息摘要、计算具备高离散程度的随机数等用途。

对称加密

对称加密就是加密和解密使用的密钥是同一个密钥。
对称加密一般用在信息须要安全交换或存储的场合,如cookie加密、通讯加密等。

WechatIMG148.jpeg

优势是:算法简单,加密解密效率高,系统开销小,适合对大量数据加密。
缺点是:加解密使用同一个密钥,远程通讯的状况下如何安全的交换密钥是个难题,若是密钥丢失,那么全部的加密信息也就咩有什么秘密可言了。

经常使用的对称加密算法有DES算法、RC算法等。对称加密是一种传统加密手段,也是最经常使用的加密手段,适用于绝大多数须要加密的场合。

非对称加密

不一样与对称加密,非对称加密和解密使用的密钥不是同一密钥,其中一个对外界公开,被称做公钥。另外一个只有全部者知道,被称做私钥。用公钥加密的信息必须用私钥才能解开,反之,用私钥加密的信息只有用公钥才能解开。
非对称加密技术一般用在信息安全传输,数字签名等场合。

WechatIMG147.jpeg

信息发送者A经过公开渠道得到接收者B的公钥,对提交信息进行加密,而后经过非安全传输通道将密文信息发送给B,B获得密文信息后,用本身的私钥对信息进行解密,得到原始的明文信息。

数字签名则相反,签名者用本身的私钥对信息进行加密,而后发送给对方,接收方用签名者的公钥对信息进行解密,得到原始明文信息,因为私钥只有签名者本身拥有,所以该信息是不可抵赖的,具备签名的性质。

在实际应用中,经常会混合使用对称加密和非对称加密。先使用非对称加密技术对对称密钥进行安全传输,而后使用对称加密技术进行信息加密解密与交换。而有时,对同一个数据两次使用非对称加密,可同时实现信息安全传输和数字签名的目的。

非对称加密的经常使用算法有RSA算法等。HTTPS传输中浏览器使用的数字证书实质上是通过权威机构认证的非对称加密的公钥。

应用层相关问题

1.http与https工做方式

HTTP协议

输入一个网页:
域名解析 --> 发起TCP的3次握手 --> 创建TCP链接后发起http请求 --> 服务器响应http请求,浏览器获得html代码 --> 浏览器解析html代码,并请求html代码中的资源(如js、css、图片等) --> 浏览器对页面进行渲染呈现给用户。

其完整的工做过程可分为四步:

①链接:首先客户机与服务器须要创建链接(由TCP/IP握手链接实现)。只要单击某个超级连接,HTTP的工做开始;

②请求:创建链接后,客户机发送一个请求给服务器,请求方式的格式为:统一资源标识符(URL)、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容;

③应答:服务器接到请求后,给予相应的响应信息,其格式为一个状态行,包括信息的协议版本号、一个成功或错误的代码,后边是MIME信息包括服务器信息、实体信息和可能的内容。客户端接收服务器所返回的信息经过浏览器显示在用户的显示屏上;

④关闭:当应答结束后,浏览器和服务器关闭链接,以保证其余浏览器能够与服务器进行链接。

更完整的过程可能以下:

若是在以上过程当中的某一步出现错误,那么产生错误的信息将返回到客户端,有显示屏输出。对于用户来讲,这些过程是由HTTP本身完成的,用户只要用鼠标点击,等待信息显示就能够了。

Https协议

HTTPS握手过程包括五步:

1)浏览器请求链接;
2)服务器返回证书:证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。
服务器采用非对称加密算法(RSA)生成两个秘钥,私钥本身保留。
3)浏览器收到证书后做如下工做:

a) 验证证书的合法性;
b) 生成随机(对称)密码,取出证书中提供的公钥对随机密码加密;

浏览器即客户端使用非对称加密来加密对称加密规则,对称加密用于加密后续传输的信息。

c) 将以前生成的加密随机密码等信息发送给网站;

4)服务器收到消息后做如下的操做:

a) 使用本身的私钥解密浏览器用公钥加密后的消息,并验证HASH是否与浏览器发来的一致;得到浏览器发过来的对称秘钥。
b) 使用加密的随机对称密码加密一段消息,发送给浏览器;

5)浏览器解密并计算握手消息的HASH:若是与服务端发来的HASH一致,此时握手过程结束,以后进行通讯。

2. HTTP和HTTPS的区别

HTTP和HTTPS的基本概念

HTTP:是互联网上应用最为普遍的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可使浏览器更加高效,使网络传输减小
HTTP风险:
一、窃听风险,采用明文传输
二、篡改风险,第三方能够修改
三、冒充风险,第三方冒充他人身份进行通讯

HTTPS:是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层,HTTPS的安全基础是SSL,所以加密的详细内容就须要SSL。
HTTPS协议的主要做用能够分为两种:
一种是创建一个信息安全通道,来保证数据传输的安全;另外一种就是确认网站的真实性。

HTTPS和HTTP的区别主要以下

1) https协议须要到ca申请证书,通常免费证书较少,于是须要必定费用。
2) http是超文本传输协议,信息是明文传输,https则是具备安全性的ssl加密传输协议。
3) httphttps使用的是彻底不一样的链接方式,用的端口也不同,前者是80,后者是443。
4) http的链接很简单,是无状态的;https协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。
5) 在OSI模型中,http工做于应用层,而https工做于传输层;

3. http有状态吗?

是无状态协议

无状态是指协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。从另外一方面讲,打开一个服务器上的网页和你以前打开这个服务器上的网页之间没有任何联系。

HTTP是一个无状态的面向链接的协议,无状态不表明HTTP不能保持TCP链接,更不能表明HTTP使用的是UDP协议(无链接)。

从HTTP/1.1起,默认都开启了Keep-Alive,保持链接特性,简单地说,当一个网页打开完成后,客户端和服务器之间用于传输

4. HTTP1.0、HTTP1.一、HTTP2.0的区别?

HTTP1.0

一、默认短链接,每一个TCP链接只能发送一个请求,而创建TCP成本很高。须要使用keep-alive参数来告知服务器要创建一个长链接,

二、HTTP1.0是没有host域的,HTTP1.1才支持这个参数;

HTTP 1.1

一、在HTTP/1.1中已经默认使用Connection: keep-alive,避免了链接创建和释放的开销,但服务器必须按照客户端请求的前后顺序依次回送相应的结果,以保证客户端可以区分出每次请求的响应内容。经过Content-Length字段来判断当前请求的数据是否已经所有接收。不容许同时存在两个并行的响应。

二、支持只发送header信息(不带任何body信息),若是服务器认为客户端有权限请求服务器,则返回100,不然返回401;

三、HTTP1.1引入管道机制,即在同一个TCP链接中,能够同时发送多个请求,服务器按顺序响应。

四、引入分块传输编码机制,在耗时操做上,产生一块数据,就发送一块数据。

HTTP1.1的缺点:由于管道机制,使得多个请求可能由于先到请求比较耗时而阻塞。

HTTP2.0

一、使用了多路复用的技术,作到同一个链接并发处理多个请求,并且并发请求的数量比HTTP1.1大了好几个数量级;

二、支持header数据的压缩,HTTP2.0使用HPACK算法对header的数据进行压缩,这样数据体积小了,在网络上传输就会更快;

三、服务器推送:服务器除了对最初请求的响应外,服务器还能够额外的向客户端推送资源,而无需客户端明确的请求。

5. HTTP 请求方法

GET
GET用于信息获取。
POST
POST向服务器提交数据,能够改变服务器上的资源。
HEAD
HEAD与GET本质是同样的,区别在于主要用于获取报文首部,不返回报文主体信息。
PUT
PUT与POST极为类似,都是向服务器发送数据,但PUT一般制定了资源存放的位置,而POST没有。
DELETE
DELETE用于删除某一资源。
OPTIONS
OPTIONS用于获取当前URL所支持的HTTP请求方法
TRACE
TRACE用于追踪路径,远程诊断服务器,它会把服务器以前的请求通讯返回给客户端。

6. GET和POST差异

(1)发送机制不一样,GET通常用于查询/获取资源信息,而POST通常用于更新资源信息。

(2)GET请求的数据会附在URL以后,POST把提交的数据放置在HTTP请求体中

(3)GET方式提交的数据最多只能是1024字节(取决于操做系统的支持),POST理论上没有数据量的限制(取决于服务器的处理能力)。

(4)POST的安全性比GET的安全性高。经过GET提交数据,用户名和密码会以明文的形式出如今URL

(5)GET请求会被浏览器自动缓存,而POST不会,除非手动设置。在浏览器回退时,GET是无害的,POST会再次提交请求。GET请求参数会被完整保留在浏览历史记录中,而POST中的参数不会被保留

(6)在发送请求时,GET产生一个TCP数据包,服务器响应200POST产生两个TCP数据包,浏览器先发送header,响应100,再发送data,响应200.

(7)GET请求只能进行url编码,而POST支持多种编码方式。

7. DNS是干什么的??

1) 主机解析域名的顺序:找缓存、找本机的 hosts文件、找 DNS服务器
2) DNS协议运行在 UDP协议之上,使用端口号 53
3) 根服务器: ISPDNS服务器还找不到的话,它就会向根服务器发出请求,进行递归查询( DNS服务器先问根域名服务器 .com域名服务器的 IP地址,而后再问 .com域名服务器,依次类推)

十个过程:

浏览器先检查自身缓存中有没有被解析过这个域名对应的ip地址;

② 若是浏览器缓存没有命中,浏览器会检查操做系统缓存中有没有对应的已解析过的结果。在windows中可经过c盘里hosts文件来设置;

③ 还没命中,请求本地域名服务器来解析这个域名,通常都会在本地域名服务器找到;

④ 本地域名服务器没有命中,则去根域名服务器请求解析;

⑤ 根域名服务器返回给本地域名服务器一个所查询域的主域名服务器

⑥ 本地域名服务器向主域名服务器发送请求

⑦ 接受请求的主域名服务器查找并返回这个域名对应的域名服务器的地址

⑧ 域名服务器根据映射关系找到ip地址,返回给本地域名服务器;

⑨ 本地域名服务器缓存这个结果;

本地域名服务器将该结果返回给用户

运输层相关问题

1. HTTP keep-aliave 和TCP keepaliave

HTTP的Keepalive,顾名思义,目的在于延长链接的时间,以便在同一条链接中传输多个HTTP请求。

HTTP服务器通常会提供Keepalive Timeout参数,用来决定链接保持多久,何时关闭链接。

当链接使用了Keepalive功能时,对于客户端发送过来的一个请求,服务器端会发送一个响应,而后开始计时,

若是通过Timeout时间后,客户端没有再发送请求过来,服务器端就把链接关了,再也不保持链接了。

TCPKeepalive,是挂羊头卖狗肉的,目的在于看看对方有没有发生异常,若是有异常就及时关闭链接。

当传输双方不主动关闭链接时,就算双方没有交换任何数据,链接也是一直有效的。

若是这个时候对端、中间网络出现异常而致使链接不可用,本端如何得知这一信息呢?

答案就是保活定时器。它每隔一段时间会超时,超时后会检查链接是否空闲过久了,若是空闲的时间超过了设置时间,就会发送探测报文。而后经过对端是否响应、响应是否符合预期,来判断对端是否正常,
若是不正常,就主动关闭链接,而不用等待HTTP层的关闭了。

2. 详细说一下TCP协议,三次握手传输的内容?13种状态

图片 1.png

1) 第一次握手:创建链接。客户端发送链接请求报文段,将SYN位置为1,Sequence Number为x;而后,客户端进入SYN\_SEND状态,等待服务器的确认;

2) 第二次握手:服务器收到SYN报文段。服务器收到客户端的SYN报文段,须要对这个SYN报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number+1);同时,本身本身还要发送SYN请求信息,将SYN位置为1,Sequence Number为y;服务器端将上述全部信息放到一个报文段(即SYN+ACK报文段)中,一并发送给客户端,此时服务器进入SYN\_RECV状态;

3) 第三次握手:客户端收到服务器的SYN+ACK报文段。而后将Acknowledgment Number设置为y+1,向服务器发送ACK报文段,这个报文段发送完毕之后,客户端和服务器端都进入ESTABLISHED状态,完成TCP三次握手。

那四次分手呢?

当客户端和服务器经过三次握手创建了TCP链接之后,当数据传送完毕,确定是要断开TCP链接的啊。那对于TCP的断开链接,这里就有了神秘的“四次分手”。

1) 第一次分手:主机1(可使客户端,也能够是服务器端),设置Sequence Number和Acknowledgment Number,向主机2发送一个FIN报文段;此时,主机1进入FIN\_WAIT\_1状态;这表示主机1没有数据要发送给主机2了;

2) 第二次分手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机1进入FIN\_WAIT\_2状态;主机2告诉主机1,我“赞成”你的关闭请求;此时主机2进入CLOSE\_WAIT状态

3) 第三次分手:主机2向主机1发送FIN报文段,请求关闭链接,同时主机2进入LAST\_ACK状态;

4) 第四次分手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,而后主机1进入TIME\_WAIT状态;主机2收到主机1的ACK报文段之后,就关闭链接;此时,主机1等待2MSL后依然没有收到回复,则证实Server端已正常关闭,那好,主机1也能够关闭链接了。

5) 六大标志位

SYN,同步标志位;ACK确认标志位;PSH传送标志位;FIN结束标志位;RST重置标志位;URG紧急标志位;seq序号;ack确认号

3. TCP为啥挥手要比握手多一次?

由于当处于LISTEN状态的服务器端收到来自客户端的SYN报文(客户端但愿新建一个TCP链接)时,它能够把ACK(确认应答)和SYN(同步序号)放在同一个报文里来发送给客户端。但在关闭TCP链接时,当收到对方的FIN报文时,对方仅仅表示对方已经没有数据发送给你了,可是你本身可能还有数据须要发送给对方,则等你发送完剩余的数据给对方以后,再发送FIN报文给对方来表示你数据已经发送完毕,并请求关闭链接,因此一般状况下,这里的ACK报文和FIN报文都是分开发送的。

4. 为何必定进行三次握手,不是两次?

采用两次握手,那么若Client向Server发起的包A1若是在传输链路上遇到的故障,致使传输到Server的时间至关滞后,在这个时间段因为Client没有收到Server的对于包A1的确认,那么就会重传一个包A2,假设服务器正常收到了A2的包,而后返回确认B2包。因为没有第三次握手,这个时候Client和Server已经创建链接了。再假设A1包随后在链路中传到了Server,这个时候Server又会返回B1包确认,可是因为Client已经清除了A1包,因此Client会丢弃掉这个确认包,可是Server会保持这个至关于“僵尸”的链接。

因此采用两次握手,有可能会浪费Server的网络资源。
还有,经过seq号和ACK号协商接下来发送数据的开始序号

5. 四次挥手能不能变成三次挥手呢?

答案是可能的。

TCP是全双工通讯,Cliet在本身已经不会在有新的数据要发送给Server后,能够发送FIN信号告知Server,这边已经终止Client到对端Server那边的数据传输。可是,这个时候对端Server能够继续往Client这边发送数据包。因而,两端数据传输的终止在时序上是独立而且可能会相隔比较长的时间,这个时候就必须最少须要2+2 = 4 次挥手来彻底终止这个链接。可是,若是Server在收到Client的FIN包后,在也没数据须要发送给Client了,那么对Client的ACK包和Server本身的FIN包就能够合并成为一个包发送过去,这样四次挥手就能够变成三次了(彷佛linux协议栈就是这样实现的)。

6. 传输层功能

传输进程到进程的逻辑通讯,即所说的端到端的通讯,而网络层完成主机到主机之间的逻辑通讯;

7. TCP与UDP的区别?应用场景都有哪些?

1) TCP面向链接(如打电话要先拨号创建链接);UDP是无链接的,即发送数据以前不须要创建链接

2) TCP面向字节流,UDP面向数据包

字节流:发送端执行的写操做数和接收端执行的读操做数之间没有任何数量关系。

3) TCP提供可靠的服务。也就是说,经过TCP链接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付

Tcp经过校验和,重传控制,序号标识,滑动窗口、确认应答实现可靠传输。如丢包时的重发控制,还能够对次序乱掉的分包进行顺序控制。

4) UDP具备较好的实时性,工做效率比TCP高,适用于对高速传输和实时性有较高的通讯或广播通讯。

5) 每一条TCP链接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通讯

6) TCP对系统资源要求较多,UDP对系统资源要求较少。

7) 若通讯数据完整性需让位与通讯实时性,则应该选用 TCP 协议(如文件传输、重要状态的更新等);反之,则使用 UDP 协议(如视频传输、实时通讯等)。

8) UDP:DNS SNMP(???

8. 为何UDP有时比TCP更有优点?

1) 网速的提高给UDP的稳定性提供可靠网络保障,丢包率很低,若是使用应用层重传,可以确保传输的可靠性。

2) TCP为了实现网络通讯的可靠性,使用了复杂的拥塞控制算法,创建了繁琐的握手过程,因为TCP内置的系统协议栈中,极难对其进行改进。

3) 采用TCP,一旦发生丢包,TCP会将后续的包缓存起来,等前面的包重传并接收到后再继续发送,延时会愈来愈大,基于UDP对实时性要求较为严格的状况下,采用自定义重传机制,可以把丢包产生的延迟降到最低,尽可能减小网络问题对游戏性形成影响。

9. TCP可靠性保证

一、差错 TCP16位校验和(丢弃等超时重传)

二、丢包 超时重 传+确认(在规定时间没有收到对方确认)

三、失序 序号(根据序号重排)

四、重复 序号(根据序号丢弃)

1.TCP通讯创建在有链接的基础上,如发起connect链接

2.序号

TCP首部的序号字段用来保证数据能有序提交给应用层,TCP把数据当作无结构的有序的字节流。表示的是我方(发送方)这边,这个packet的数据部分的第一位应该在整个data stream中所在的位置。

3.发送应答机制、确认

发送端发出的每个TCP报文段必须获得对端的应答,才认为这个TCP报文段接收成功。

TCP首部的确认号是指望收到对方的下一个报文段的数据的第一个字节的序号;

4. 超时重传

发送端发出一个TCP报文段后启动定时器,若是在定时时间内未接收到应答,他将重发这一报文段并重置重传定时器。

5. 流量控制

TCP采用大小可变的滑动窗口进行流量控制,窗口大小的单位是字节。

发送窗口在链接创建时由双方商定。但在通讯的过程当中,接收端可根据本身的资源状况,随时动态地调整对方的发送窗口上限值(可增大或减少)。

1) 窗口

接受窗口rwnd,接收端缓冲区大小。接收端将此窗口值放在 TCP 报文的首部中的窗口字段,传送给发送端。
拥塞窗口cwnd,发送缓冲区大小。
发送窗口swnd, 发送窗口的上限值 = Min \[rwnd, cwnd\]

6. 拥塞控制

TCP报文段最终以IP数据包发送的,而IP数据包到达接收端可能乱序、重复,TCP对接收到的TCP报文段重排、整理,再交付给应用层。
TCP头部有个16位校验和。接收端对TCP报文段执行CRC算法来检测TCP报文段在传输过程当中是否损坏。

流量控制与拥塞控制的区别

所谓拥塞控制就是防止过多的数据注入到网络中,这样可使网络中的路由器或链路不致过载。拥塞控制所要作的都有一个前提,就是网络能承受现有的网络负荷。流量控制每每指的是点对点通讯量的控制,是个端到端的问题。流量控制所要作的就是控制发送端发送数据的速率,以便使接收端来得及接受。

相关文章
相关标签/搜索