浅析计算机网络

·  阅读 259

OSI与TCP/IP各层的结构与功能,都有哪些协议

  • 应用层

应用层的任务是通过应用进程间的交互来完成特定的网络应用。应用层协议定义的是应用进程间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议,比如虚名系统DNS,支持万维网应用的HTTP,支持电子邮件的SMTP等,我们把应用层交互的数据单元成为报文。

域名系统 域名系统简称DNS,是因特网的一项核心服务,它作为可以将域名和IP地址相互映射的一个分布式数据库,能够使人更方便的访问互联网,而不用记住能够被机器直接读取的IP数串,例如:一个公司的Web网站可以看作是它在网上的门户,而域名相当于门牌地址。 HTTP协议 超文本传输协议,是互联网应用最广泛的一种网络协议,所有的www(万维网)文件必须遵守这个标准,设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。

  • 运输层

运输层的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。

运输层主要使用的协议 传输控制协议TCP: 提供面向连接的,可靠的数据传输服务。 用户数据协议UDP: 提供无连接的,尽最大努力的数据传输服务(不保证数据传输的可靠性)。

  • 网络层 网络层负责为分组交换网上的不同主机提供通信服务。在发送数据时,网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在TCP/IP中,由于网络使用IP协议,因此分组也叫IP数据报,简称数据报。 网络层的另一个任务是选择合适的路由,使源主机运输层所传下来的分株,能通过网络层中的路由器找到目的主机。 互联网是由大量的异构网络通过路由器相互连接起来的,互联网使用的网络协议是无状态的网络协议和许多路由选择协议,所以互联网的网络层也叫做网际层或者IP层。

  • 数据链路层 数据链路层通常简称为链路层。两台主机之间的数据传输,总是在一段一段的链路上传送的,这就需要专门的链路层协议。在两个相邻节点之间传送数据时,数据链路层将网络层交下来的IP数据报组装成帧,在两个相邻节点的链路层上传送帧。每一帧包括数据和必要的控制信息(如同步信息、地址信息、差错控制等)。 在接收数据时,控制信息使接收端能够知道一个帧从那个比特开始和到那个比特结束。这样,数据链路层在收到一个帧后,就可以从中提取出数据部分,上交给网络层。控制信息还使接收端能够检测到所有的帧中有无差错。如果发现差错,数据链路层就能简单地丢弃这个出了差错的帧,以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层时出现差错,那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂一些。

  • 物理层 在屋里层上传送的数据单位是比特,物理层的作用是实现相邻计算机节点之间比特流的透明传送,尽可能的避免掉具有传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。

三次握手和四次挥手(重点)

为了准确无误的把数据送达目的地,TCP使用三次握手策略

三次握手过程

  • 第一次握手:客户端发送syn包(syn=x)到服务器,并进入SYN_SEND状态,等待服务器确认
  • 第二次握手:服务端接收到syn包后,必须确认客户端的SYN(ack=x+1),同时自己发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态。
  • 第三次握手:客户端收到服务器的SYN+ACK包后,向服务器发送确认包(ack=y+1),此包发送完毕后,客户端和服务器端进入ESTABLSHED状态,完成三次握手。
  • 握手过程中传送的包里不含数据,三次握手完毕后,客户端与服务器端才正式开始传送数据,理想状态下,TCP一旦建立,在通信双方任何一方主动关闭连接之前,TCP连接都将一直保持下去。

为什么需要三次握手

三次握手的目的是建立可靠的通信

  • 第一次握手,客户端什么都不能确认,而服务器端确认了对方发送正常。
  • 第二次握手,客户端确认了自己发送、接收正常吗对方发送、接收正常,服务器端也确认了自接收正常,对方发送正常。
  • 第三次握手,客户端确认了自己发送、接收正常,对方发送、接收正常,服务器端确认了自己发送、接收正常,对方发送、接收正常。

为什么要传回SYN

接收端传回发送端所发送的SYN是为了告诉发送端,我接收到的信息确实就是你发送的信号了。

传了SYN为什么还要传ACK

双方通信无误必须是两者相互发送的信息都无误,传了SYN,证明发送方到接收方的通道没问题,但是接收方到发送方的通道还需要ACK信号进行验证。

第三次握手失败怎么办

第三次失败的话,只有客户端处于成功状态,服务器端没有接收到客户端的ACK,需分情况

  • 如果客户端发送的ACK丢失了,但是发送的下一个数据包没有丢失,则服务器端接收到下一个数据包(这个数据包里也会带上ACK信息),能够进入正常的ESTABLISH状态。
  • 如果服务器和客户端没有数据发送,或者是服务器端想发送但是发不了(因为没有收到客户端的ACK),服务器会有定时器控制发送第二步的SYN+ACK包,如果客户端再次发送ACK成功,则建立连接。
  • 如果一直不成功,服务器会有超时设置,超时之后会给客户端发送RTS报文,进入CLOSED状态,防止SYN洪泛攻击。

为什么需要三次握手,两次不可以吗?为什么?

为了防止已失效的链接请求报文突然又传送到了服务器,因而产生错误。客户端发送的链接请求报文并未丢失,而是在某个网络节点上长时间滞留了,以至延误到链接释放以后的某个时间才到达服务器端,这时,服务器端误以为是客户端新发送的链接请求,于是向客户端发送确认数据包,同意建立连接。如果不采取三次握手,那么只要服务器端发送了确认数据包,新的链接就建立了,由于此时客户端并没有发送链接请求,所以不会理服务器端的确认,也不会与服务器端通信,而这时服务器端一直在等待客户端的请求,这样服务器端就白白浪费了一定的资源。若采用三次握手,在这种情况下,由于服务器端没有收到客户端的确认,便会知道客户端并没有建立请求,就不会建立连接。

四次挥手过程

  • 第一次挥手:客户端主动关闭并发送一个FIN,用来关闭客户端到服务器端的数据传送,也就是客户端告诉服务器端:我已经不会给你发送数据了(若在FIN包之前发送到的数据,如果没有接收到对应的ACK确认报文,客户端依然重发这些数据),但是此时客户端还是可以接受数据,此时客户端进入FIN-WAIT1状态。
  • 第二次挥手:服务端收到FIN包后,发送一个ACK给客户端,确认序号为接收序号+1,此时服务器进入CLOSE-WAIT状态。
  • 第三次挥手:服务端发送一个FIN,同来关闭服务端到客户端之间的数据传送,也就是告诉客户端:我的数据也发送完了,不会再给你发送数据了,此时服务器进入LAST-ACK状态。
  • 第四次挥手:客户端收到FIN后,发送一个ACK给客户端,确认序号为收到序号+1,服务器端进入CLOSED状态,客户端进入TIME-WAIT状态,此时TCP链接还没有释放,必须经过2*MSL(最长报文段寿命)的时间后,当客户端撤销响应的TCB后,才进入CLOSED状态。

为什么客户端需要等待2MSL

  • 保证客户端发送的最后一个ACK报文能够到达服务器,因为这个报文可能丢失,站在服务器的角度看,我已经发送了FIN+ACK报文请求断开,客户端还没有给我回应,应该是我发送的请求断开报文客户端没有接收到,所以服务器重新发送一次。而客户端可以在这个2MSL时间内收到这个重传的报文,接着给出回应报报文,并且重启2MSL计时器。
  • 防止类似于三次握手中提到的已经失效的链接请求报文出现在本链接中,客户端发送最后一个确认报文之后,在这个2MSL时间内,就可以使本链接持续的时间内所产生的所有报文段都从网络中消失,这样新的链接中不会出现旧的链接的请求报文。

为什么需要四次挥手

任何一方都可以在数据传送结束后发出链接释放的通知,待对方确认后进入半关闭状态,当另一方也没有数据要发送的时候,则发出链接释放通知,对方确认后就完全关闭了TCP链接。

如果已经建立了链接,但是客户端发生了故障怎么办?

TCP设有保活计时器,客户端如果故障,服务器不能一直等下去,服务器每次收到一次客户端请求后都会重新复位这个计时器,时间通常为两小时,若两小时还没收到客户端的任何数据,服务器会发送一个探测报文段,以后每隔75s发送一个,若一连发送10个探测报文仍然没有反应,服务器认为客户端发生故障,便会关闭连接。

TCP和UDP

TCP(传输控制协议)简介

  • 面向连接的、可靠的、基于字节流的传输层通信协议
  • 将应用层的数据流分割为报文段并发送给目标节点的TCP层
  • 报文段都有序号,对方收到则发送ACK确认,为收到则重传

TCP的报文头

  • 源端口:发送方的端口号
  • 目的端口:接收方的端口号
  • 序号:TCP报文段的序号
  • 确认序号:接收方接收到了序号为x的报文段,期待收到序号为x+1为起始的报文段
  • 数据偏移:报文段在整个报文中偏移的字节量
  • 保留域:备用区
  • 标识位置:URG(紧急信号)、ACK(确认标志位)、PSH(为1则收到信息后立即交给进程,无需在队列中等待)、RST(重置连接)、SYN(请求链接)、FIN(结束连接)。
  • 校验和:检验数据是否正确

SYN Flood洪泛攻击

  • 原理 是利用三次握手的规则,在客户端向服务器端发送请求后,在服务器端发送SYN+ACK后下线,服务器则无法收到ACK确认,服务器会不断重试,重试间隔为1s,2s,4s,8s,16s,32s,在linux默认状况下会等待63s,如果有大量的连接重复此过程,则会造成服务器连接队列耗尽。
  • 防护措施 Linux设置了TCP-SYN-Cookies参数,若为正常连接,客户端发回SYN Cookie,如果为异常连接,就不发回,但也不会影响到连接队列。

TCP协议如何保证可靠运输

  • 应用数据被分割为TCP认为最适合发送的数据块。
  • TCP给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传递给应用层。
  • 校验和:TCP将保持它首部和数据的校验和,这是一个端到端的校验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差异,TCP将丢弃这个报文和不确认收到此报文段。
  • TCP的接收端会丢弃重复的数据。
  • 流量控制:TCP连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端的缓冲区能接纳的数据。当接收方来不及处理发送的数据时,能提示发送方降低发送的速率,防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议(TCP利用滑动窗口实现流量控制)。
  • 拥塞控制:当网络拥塞时,减少数据的发送。
  • 停止等待协议:为了实现可靠性传输,它的基本原理是每发完一个分组就停止发送,等待对方确认。在收到确认后再发送下一个分组。
  • 超时重传:当TCP发出一个段后,启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重新发送这个报文段。

自动重传请求ARQ协议

  • 停止等待协议中超时重传指的是只要超过一段时间仍然没有收到确认,就重传前面发送的分组(认为刚才发送过去的分组丢失了)。因此每发完一个分组需要设置一个超时计数器,其重传时间应比在分组传输的平均往返时间更长一些这种自动重传方式成为ARQ协议。
  • 优点:简单
  • 缺点:信道利用率低

连续ARQ协议

  • 连续ARQ协议可提高信道利用率,发送方维持一个发送窗口,只要位于发送窗口内的分组可以连续发送出去,而不需要等待对方确认,接收方一般采取累计确认,对按照到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经正确收到了。
  • 优点:信道利用率高,容易实现,即使数据丢失,也不必重传。
  • 缺点:不能想发送方反应出接收方已经正确收到的所有分组的信息。比如:发送方发送了五条消息,中间第三条丢失,这是接收方只能对前面两个发送确认,发送方无法知道后三个分组的下落,而只能将后三个重新发送。

滑动窗口

  • TCP利用滑动窗口实现流量控制的机制。
  • 滑动窗口:是一种流量控制技术,早起的网络通信中,通信双方不会考虑网络的拥挤情况直接发送数据。但是由于大家不知道网络拥塞情况,同时发送数据,导致中间节点阻塞掉包,谁也发不了数据,所以就有了滑动窗口机制来解决此问题。
  • TCP采用滑动窗口来进行传输控制,滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接受数据。发送方可以通过滑动窗口的大小来确认应该发送多少字节的数据。当滑动窗口为0时,发送方一般不能再发送数据包,但是有两种情况除外,一种是可以发送紧急数据,例如:允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个1字节的数据报来通知接收方重新声明它希望接受的下一字节及发送的滑动窗口大小。

流量控制

  • TCP利用滑动窗口实现流量控制。
  • 流量控制是为了控制发送方发送速率,保证接收方来得及接收。
  • 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为0,则发送方不能发送数据。

拥塞控制

  • 在某段时间里,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能会变差。这种情况叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或者链路不过载。拥塞控制所要做的都有一个前提,就是网络能承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是点对点通信量的控制,是端到端的问题。流量控制所要做的就是抑制发送端发送数据的速率,以便使接收端来得及接收。
  • 为了进行拥塞控制,TCP发送方要维持一个拥塞窗口的状态变量,拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接收窗口中较小的一块。
  • TCP的拥塞控制采用了四种算法,即:慢开始、拥塞避免、快重传、快恢复。在网络层也可以使路由器采用适当的分组丢弃策略(如主动队列管理AQM),以减少网络拥塞的发生。
慢开始

慢开始算法的思想是当主机开始发送数据时,如果立即把大量的数据字节注入到网络中,可能会引起网络阻塞,因为现在还不知道网络的符合情况。较好的方法是先探测一下,即由小到大逐渐增大发送窗口,也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1,每经过一个轮播轮次,cwnd加倍。

拥塞避免

拥塞避免算法的思想是让拥塞窗口cwnd缓慢增大,即每经过一个往返时间RTT就把发送方的cwnd加1.

快重传和快恢复

在TCP/IP中,快速重传和恢复(FRR)是一种拥塞控制算法,它能快速恢复丢失的数据包。没有FRR,如果数据包丢失了,TCP将会使用定时器来要求传输暂停,在暂停的时间内,没有新的或复制的数据包被发送。有了FPP。如果接收端接收到了一个不按顺序的数据段,会立即给发送端发送一个重复确认。如果发送端接收到了三个重复确认,会假定确认中指出的数据段丢失了,并立即重传这些丢失的数据段。有了FRR,就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时,FRR能最有效的工作,当有多个数据信息包在某一段很短的时间内丢失时,不能很有效的工作。

UDP特点

  • 面向非连接的,传输速度快
  • 支持同时向多个客户端传输信息
  • 报文段报文头只有8个字节,额外开销小
  • 吞吐量只受限于数据生成速率、传输速率以及机器性能
  • 尽最大努力交付,不保证可靠交付,不需要维持复杂的连接状态表
  • 面向报文,不对应用程序提交的信息进行拆分或者合并

TCP和UDP的区别

  • UDP在传送数据之前不需要建立连接,远地主机在收到UDP报文后,不需要给出任何确定,虽然UDP不需要给出任何确认,但是UDP传输速度快,适用于QQ语音、QQ直播、直播等等(即时通信)。
  • TCP提供面向连接的服务。在传送数据之前必须先建立连接,数据传送结束后要释放连接。TCP不提供广播或者多播服务,由于TCP要提供可靠的、面向连接的运输服务(TCP的可靠性主要体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完后,还会断开链接用来节约系统资源),这是的TCP增加了许多开销,不仅使协议数据单元的首部增大很多,还要占用多处理机资源,TCP一般用于文件传输、发送和接收邮件、远程登录等场景。
  • TCP是面向连接的,UDP是无连接的
  • TCP比UDP可靠
  • TCP有序,UDP可能无序
  • TCP使用字节流传输数据,UDP使用数据报文段
  • UDP传输速度比TCP快
  • TCP所需资源比UDP多
  • TCP首部字节长度为20~60,而UDP为8个字节

HTTP协议

HTTP协议简介

  • HTTP:超文本传输协议
  • 支持客户端/服务器模式
  • 简单高效、灵活
  • 无连接:限制每次连接都只处理一个请求,但是在HTTP1.1起,默认使用长连接
  • 无状态:HTTP版本现在常用的有1.0和1.1,还有2.0,1.1在1.0的基础上做了keep-alive长连接技术,而2.0虽然在思想上都显得更加合理,但是1.1基本能满足日常需求且更换2.0消耗太大,所以2.0暂时没有被推广开。
  • HTTP请求报文
  • HTTP报文头
  • 请求/相应的步骤 1.客户端连接到Web服务器 2.发送HTTP请求 3.服务器接收请求并返回HTTP相应 4.释放TCP连接(如果是keep-alive则保持一段时间) 5.客户端解析HTML内容

在浏览器中输入一个url地址,显示主页的过程,以及使用到的协议

  • 首先进行DNS解析,将访问的域名解析为IP地址,解析是由近到远的,首先在浏览器缓存中寻找是否有对应的IP,如果没有则进入系统缓存,如果还是没有则按照路由器缓存、IPS服务器缓存、根域名缓存、顶级域名服务器缓存这样一路查找,直到找到了则停止查找,直接返回。然后进行TCP连接,默认端口为80,进行三次握手,建立连接后发送HTTP请求,服务器处理请求并返回HTTP报文,浏览器解析并渲染页面,左后连接结束。
  • 使用到的协议 DNS协议:获取域名对应的IP TCP:与服务器建立TCP连接 IP:建立TCP协议时,需要发送数据,发送数据在网络层使用IP协议 OPSF:IP数据包在路由器之间,路由选择使用OPSF协议 ARP:路由器在服务器通信时,需要将ip地址转换为MAC地址,需要使用ARP协议 HTTP:在TCP建立完成后,使用HTTP协议访问网页

GET和POST的区别

  • HTTP报文层面:GET请求将请求信息放在URL后面,POST放在报文体中,相对于GET安全一些。
  • 理论上讲,POST是没有大小限制的,但是GET存储的信息有大小限制(最多为2048个字符)。
  • GET只允许携带ASCII字符的数据,而POST没有限制
  • 数据库方面:GET符合幂等性(对数据库的一次或多次操作,结果是一致的)和安全性(对数据库一次或多次操作,没有改变数据库中的数据),GET是用来做查询的,不会改变数据库中的数据。
  • POST插入,每次请求都可能不一样。
  • GET可以被CDN缓存,被存储,在服务量巨大的环境下,又有大部分数据时只读数据,所以不用让服务器完全处理,就可以使用GET,但是POST不行,POST必须交给服务器处理。

Cookie和Session的区别

  • Cookie时客户端解决方案,有服务器发给客户端的特殊信息,以文本的形式存储在客户端上。

  • Cookie的使用过程: 1.用户向服务器发送个人识别信息,服务器也向客户端发送Cookie文件。 2.客户端再次发起请求时,也会吧Cookie发送回去。 3.服务器会获取Cookie从而生成与客户端相对应的内容。

  • Session时服务器端的解决方案,Session实在服务器上保存的信息。服务器解析客户端请求并操作SessionId,按需保存状态信息,如果客户端包含SessionId则直接使用,如果不包含则创建一个。

  • Session实现方式: 1.使用Cookie实现:客户端像服务器发送请求,服务器返回响应报文并SetCookie,Cookie中含有JSESSIONID-XXXXX,客户端之后每次请求都会携带这个Cookie,服务器根据这个Cookie中的Session提供响应的内容。 2.使用URL回写:使用URL回写即在URL地址中携带JSESSIONID这个参数。 3.Tomcat同时支持Cookie和URL回写,默认使用Cookie,当浏览器拒绝Cookie时,使用URL回写的方式实现Session。

  • 区别:Cookie是以文件的形式存储在客户端,而Session实在服务器端进行处理的,Session相对于Cookie更安全,因为Cookie存储在客户端,容易被修改,而Session存储在服务器端,无法被修改,但Session会占用服务器资源,影响服务器性能。

状态码

HTTP和HTTPS

HTTP和HTTPS的区别

  • HTTPS:超文本传输安全协议
  • HTTP:HTTP+TCP+IP
  • HTTPS:HTTP+(SSL或者TLS)+TCP+IP
  • HTTPS需要到CA申请证书,而HTTP不需要
  • HTTPS的证书是收费的,而HTTP不收费
  • HTTPS默认端口为443,而HTTP为80
  • HTTPS是有状态协议,HTTP是无状态协议
SSL:安全套接层

SSL是为网络通信提高安全及数据完整性的一种安全协议,树操作系统对外的API,SSL3.0后更名勒TLS,采用身份验证和数据加密保证网络通信安全和数据的完整性。

加密方式
  • 对称加密:对称加密是一种可以进行解密的加密过程,特点就是将一个数据按照一定过程加密后,按照这个过程的反过程一定可以将这个数据进行解密,效率高,但是安全性低。对称加密又称为私钥加密,发送方和接收方要选择和使用同一私钥,并且要保证不能泄漏私钥,这样才能保证数据的完整性和保密性。
  • 非对称加密:非对称加密的特点是加密使用的密钥和解密使用的密钥是不相同的,非对称加密又称为公钥加密,加密使用的密钥是公开的,而解密使用的密钥只有接收方知道。将一条数据按照一定的过程加密,按照这个过程的反过程不能解密,需要使用另外一个密钥进行解密,非对称加密安全系数高,但是效率低。
  • Hash加密:将任意长度的信息转换为固定长度的值,加密的数据是不可逆的,常见的Hash加密方式有MD5加密。
  • 数字签名:在信息后加一段Hash值,证明某个消息或者文件是某人发出的,且可以证明信息没有被修改过。
  • HTTPS使用安全证书+各种加密方式共同加密。

HTTP的长连接、短连接

  • 在HTTP1.0中默认使用短连接,也就是说,客户端和服务器每进行一次HTTP请求,就建立一次连接,任务结束就中断连接。当客户端浏览器访问某个HTML或其他类型的Web页中包含其它Web资源(例如JavaScript文件、图像文件、CSS文件等),每遇到这样一个Web资源,浏览器都会重新建立一个HTTP会话。
  • 从HTTP1.1起,默认使用长连接,用以保存连接特征。使用长连接的HTTP协议时,会在响应头中使用Connection:keep-alive这行代码。
分类:
代码人生
标签:
分类:
代码人生
标签:
收藏成功!
已添加到「」, 点击更改