- 计算机网络 - 协议

@[toc]

>> OSI七层协议

~ 物理层

两台物理机之间进行通信,机器A想机器B发送比特流,机器B接收比特流,就是物理层要做的事情;

物理层主要定义了物理设备的标准,如网线的类型,光纤的接口类型,各种传输设备的传输速率,它的作用是传输比特流,也就是01二进制数据;将它们转换为电流强弱来进行传输,到达目的地之后再转换为01字节码;

这一层的数据是比特,网卡工作再这层;


~ 数据链路层

在传输比特流的过程中,会产生错传、数据传输不完整的可能,数据链路层定义了如何格式化数据,以进行传输,以及定义了如何控制对物理层的访问;还提供错误检测和纠错,以确保数据传输的可靠性;

本层将比特数据组成帧,交换机工作在这层,对帧解码,并根据帧中包含的信息,把数据发送到正确的接收方;


~ 网络层

随着网络节点的不断增加,点对点通信时需要经过多个节点,如何找到目标节点,如何选择最佳路径,就是网络层要做的事;

网络层将网络地址转换成物理地址,并决定如何将数据从发送方路由到接收方;网络层通过综合考虑发送优先权、网络拥塞程度、服务质量、可选路由的花费,来选择节点间通信的最佳路径。

由于网络层处理,并智能指导数据传送,路由器连接网络各段,所以路由器工作再这层;此层数据成为数据包;

本层协议:ip协议;


~ 传输层

通信过程中需要发送大量的数据,海量文件传输的可能需要很长时间,而网络在通信过程中会中断好多次,此时为了保证传输大量文件时的准确性,需要对发送出去的数据进行切分,切割为一个一个的段落进行发送,那么,若其中一个段落丢失了怎么办?要不要重新传?每个段落要按顺序到达吗?这就是传输层要考虑的问题;

传输层解决了主机间的数据传输,数据间的传输可以是不同网络的,并且传输层解决了传输质量的问题;

传输协议同时同时进行流量控制,或是基于接收方可接收数据的快慢程度,规定适当的发送速率;

除此之外, 传输层按照网络可以处理的最大尺寸,将较长的数据包进行强制分割,例如,以太坊无法接受大于1500字节的数据包,发送节点的传输层将数据分割成较小的数据片,同时为每个数据片安排一个序列号,以便数据到达接收方节点的传输层时,能以正确的顺序重组,该过程称为排序;

协议:TCP、UDP协议;


~ 会话层

保证给正确的主机发送正确的封装后的信息之后,但是用户级别的体验好不好,每次都要调用TCP协议去打包?然后调用IP协议去找路由?自己去发送数据?

会话层的功能:建立和管理应用程序之间的通信,提供自动收发包,自动寻址的功能;


~ 表示层

会话层保证了应用程序自动收发包和寻址,但是要用Linux给Windows发送数据包,两个系统语法不一致,就向安装包,exe不能在Linux中执行,shell在Windows下也不能执行,于是需要表示层,来解决不同系统之间的通信语法问题;


~ 应用层

在表示层,数据将按照网络能理解的方案,进行格式化,这种格式化也因所使用的网络的类型的不同而不同,此时,虽然发送方知道自己发送的是什么东西,转换成字节数组之后的数据有多长,但是接收方不知道,所以需要应用层的网络协议,它规定发送方和接收方必须使用固定长度的消息头,消息头必须使用某种固定的组成,消息头里必须记录消息体的长度等信息,以方便接收方能正确解析发送方发送的数据;

应用层旨在让我们更方便的应用从网络中接收到的数据,没有该层,数据也能在两台主机间进行传递,只是传递的是01组成的字节数组;

协议:TCP/IP协议中的http协议;


>> OSI 开放式互联参考模型

在这里插入图片描述

数据传输从应用层开始,都会对要传输的数据头部进行处理,加上本层的一些信息,最终由物理层通过以太网、电缆等介质将数据解析成比特流,在网络中传输;数据传递到目标地址,自底而上的将对应层的头部信息解析分离出来;


>> TCP/IP协议

OSI开放式互联参考模型 定义了开放系统的层次结构,层次之间的相互关系,以及各层所包括的可能的任务,是作为一个框架来协调和组织各层所提供的服务,但是它并没有提供一个可以实现的方法,而是描述了一些概念,用来协调进程间通信标准的制定,也就是说OIS互联参考模型并不是一个标准,而是一个在制定标准时所使用的概念性的框架;

TCP/IP协议并不完全符合OSI的七层参考模型,但是可以理解成TCP/IP协议是OSI七层协议的一个实现;
OSI模型注重通信协议必要的功能是什么,TCP/IP协议更强调在计算机上实现协议应该开发哪种程序;

TCP/IP协议不只是指这两种协议,多数情况下指的是利用IP进行通信时所必须用到的协议群的统称;集体来说,TCP、IP、FTP、UDP、Telnet、HTTP等都属于TCP/IP协议,它们与TCP/IP的关系紧密,是互联网必不可少的组成部分;TCP/IP协议泛指这些协议,因此TCP/IP协议有时也称为网际协议群,

在数据传输过程中,和OSI一样,TCP/IP协议的每个分层中都会对所发送的数据附加一个头部,里面包含了每层的必要的信息,如发送的目标地址,以及协议相关的信息;

通常为协议提供的信息称之为报头的首部,要发送的内容称为数据;数据被传输到接收端之后再层层解剖出来;

在这里插入图片描述

在这里插入图片描述


~ TCP 协议

IP协议是无连接的通信协议,它不会占用两个正在通信的协议之间的通信线路,这样IP就降低了对网络线路的需求,每条线可以同时满足许多不同计算机之间的通信需要;通过IP,消息或其他数据会被分割为独立的较小的包,并通过inter网在计算机之间传输,IP负责将每个数据包路由到它的目的地,但是IP协议没有做任何事情来确认数据包是否按顺序发送,或者包是否被破坏,所以IP数据包是不可靠的,需要由它的上层协议来做出控制;

TCP传输控制协议是传输层的协议,是一种面向连接的、可靠的、基于字节流的传输层通信协议,数据传输时,应用层向TCP发送数据流,然后TCP将数据流分割成适当长度的报文段,报文段的长度,通常受该计算机连接的网络的数据链路层的最大传输单元限制,之后TCP把结果包传给IP层,由IP通过网络将数据包传送给目标节点的TCP层,TCP为了保证不丢失包,就给每个包一个序号sequence number,序号也保证了数据包到目的节点的按序处理; 接收端对已成功收到的包发回一个ACK确认,如果在发送端在合理的往返时延内没有收到确认,对应的数据包就会被假设为已丢失,并且会对其进行重传;

TCP使用奇偶校验和函数来验证数据在传输过程中是否有错误,在发送和接收时都会计算校验和;


~ TCP 报文头部

在这里插入图片描述

1、Source Port / Destination Port:源端口/目的端口;
TCP、UDP的数据包都不包含IP地址信息,因为那是IP层的事,但是TCP、UDP都有源端口、目的端口,就是说,端口属于传输层;

两个进程在计算机内部进行通信,可以有管道、内存共享、信号量、消息队列等方法进行通信的,而两个进程若需要进行通信,最基本的一个前提是能唯一的标识一个进程,根据这个唯一的标识找到对应的进程;在本地进程通信中,可以使用PID来唯一标识一个进程,但是PID(进程号)只在本地唯一,若把进程放在了两个不同的计算机,进程通信的话,PID就不够用了;

解决两台计算机通信时唯一标识一个进程的方法是:在传输层中使用协议端口号;

IP层的IP地址可以唯一标识一台主机,TCP协议和端口号可以唯一标识主机中的一个进程,所以可以使用TCP协议+IP地址+端口号作为唯一标识来标识网络中的一个进程;这种唯一标识模式称为套接字Socket

虽然通信的的重点是应用进程,但只要把要传送的报文交到目的主机的某一个合适的端口,剩下的工作就由TCP来完成了;

2、Sequence Number:序号;
TCP连接中传送的字节流中的每个字节都按顺序去编号,例如一段报文中的序号字段值是107,而携带的数据有100个字段,那么如果有下一个报文段的话,其序号就是207,

3、Acknowledgement Number:确认号; 期望收到对方的下一个报文的第一个数据字节的序号;

如B收到A发送过来的报文,其序列号字段是301,数据长度是200字节,这表明了B正确收到了A发送的到序列号301+200-1=500为止的数据,因此B期望收到A下一个数据序号的501,于是B在发送给A的确认报文段中,会把ack确认号置为501;

4、Offset:数据偏移; 由于头部有可选字段,长度不固定,因此它指出TCP报文的数据距离TCP报文的起始处有多远;

5、Reserved:保留域;

6、TCP Flags:控制位,由8个标志位组成;
(1)URG紧急指针标志;为1表示紧急指针有效,为0则忽略;
(2)ACK确认序号标志;为1表示确认号有效,为0忽略确认号字段;
(3)Pushpush标志;为1表示接收到带有push标志的数据,指示接收方接收到该报文段以后,应尽快将这个报文段交给应用程序,而不是在缓冲区排队;
(4)RST重置连接标志;用于重置由于主机崩溃或其他原因而出现错误的连接,或者用于拒绝非法的报文段,和拒绝连接请求;
(5)SYN同步序列号;用于建立连接过程;
(6)Finfinish标志,用于释放连接;为1表示发送发已经没有数据发送了,即关闭本方数据流;

7、Window:滑动窗口;
用来告知发送端、接收端的缓存大小,以此控制发送端发送数据的速率,从而达到流量控制;

8、Checksum:检验和;
指的是奇偶校验,此校验和对整个的TCP报文段,包括TCP头部、和TCP数据,以16位计算所得;由发送端计算和存储,并由接收端进行验证;

9、Urgent Pointer:紧急指针;
只有当TCP Flags的URG=1才有效,指出本报文段中的紧急数据的字节数;

10、TCP Options:可选项;
长度可变,定义一些其他的可选参数;


~ TCP 三次握手

当应用程序希望通过TCP与两一个应用程序通信时,它会发送一个通信请求,这个请求必须被送到一个确切的地址,在双方握手之后,TCP将在2个应用之间建立一个全双工的通信,这个全双工的通信将占用两个计算机之间的通信线路,直达它被一方或双方关闭为止;

全双工指的是计算机A可以给计算机B发送信息,在A给B发送信息的同时,B也能给A回发信息;

三次握手是为了建立连接;

在这里插入图片描述

A和B首次进行通信,客户端和服务端都处于close状态,假设主动打开连接的是客户端,被动打开连接的是服务端;

1、TCP服务器进程先创建传输控制块TCB,时刻准备接收其他客户进程发送过来的连接请求,此时服务端进入了Listen监听的状态;

2、TCP客户端进程创建传输控制块TCB,然后向服务器发送连接请求报文,报文头中的TCP Flags控制位的SYN=1,序列号seq设置初始值为x(x可以是一个任意的正整数),此时TCP客户端进程就进入一个SYN-SENT同步已发送的状态,此时发送到服务端的数据包报文段被称为SYN报文段,它是不能携带数据的,但是要消耗掉一个序号,这就是第一次握手

3、服务器接收到请求报文之后,如果同意连接,就向客户端发送确认报文;确认报文中的TCP Flags控制位的SYN=1,ACK=1,确认号ack=x+1,(上个报文消耗的一个字节+seq的初始值x);为自己的缓存初始化一个序列号:seq=y;此时服务器就进入到了SYN-RCVD同步已收到的状态;这个报文也不能携带数据,但是消耗一个序号,这就是第二次握手

4、TCP客户进程收到确认报文之后,还要给服务器一个确认,确认报文的TCP Flags控制位的ACK=1,序列号seq=x+1,ack=y+1(服务器发送的seq=y + 确认报文消耗的一个序列);此时TCP连接建立,客户端就进入established已建立连接的状态;TCP规定这个ACK报文段可以携带数据,也可以不携带数据,不携带数据就不会消耗序列号,这就是第三次握手

5、服务器收到客户端的确认后,就会进入到established状态,此后通信双方就可以进行通信了;

在这里插入图片描述

为什么需要三次握手才能建立起连接

主要是为了初始化Sequence Number的初始值;
通信双方要互相通知对方自己的初始化的Sequence Number,作为以后的通信需要的序列号,以保证应用层接收到的数据不会因为网络上的传输的问题而乱序,TCP会用这个序列号来拼接数据,因此在服务器向客户端回发它的seq完成第二次握手之后,客户端还需要发送确认报文给服务器,告诉服务器客户端已经收到服务器的初始化的seq的值了;

首次握手的隐患 - SYN超时

如果服务端接收到客户端发送的SYN包之后,回复客户端SYN-ACK包,回复之后,客户端就掉线了,此时服务端没有收到客户端发送回来的ACK确认,这个连接就会处于一个中间状态:没有成功也没有失败;

于是,服务端在一定时间内没有收到客户端的回复,就会重发SYN-ACK,Linux下默认重试五次,重试间隔为1、2、4、8、32秒,五次重试总共63秒之后,没有收到回复,就会判定为超时,TCP就会断开这个连接;

这就会使服务器遭到SYN Flood风险:恶意程序会给服务器发送一个SYN报文,发送之后就下线,于是服务器就要默认等待63秒,才会断开这个连接,这样攻击者就会把服务器的SYN连接对应的资源耗尽,让正常的连接请求不能处理;

Linux解决方案:使用tcp_syncokkies参数;当SYN队列满了之后,TCP会通过原地址端口、目标地址端口、时间戳,创建一个特殊的Sequence Number作为SYN Cookie,发送给客户端;如果是攻击者,是不会响应的,正常连接的客户端就会回发这个SYN Cookie给服务端,服务端可以根据这个Cookie建立连接;通过SYN Cookie,即使此时的SYN队列满了,新的连接请求不在队列中,依然能建立连接;

建立连接之后,客户端出现故障怎么办

TCP设有保活机制:在一段时间(保活时间keep live time),连接处于非活动状态,开启保活功能的一端,将向对方发送一个保活探测报文,如果发送端没有收到响应报文,经过一个已经提前配置好的保活时间间隔,将继续发送保活报文,直到发送探测报文的次数达到保活探数仍未收到响应,这时对方主机将被确认为不可达,连接将被中断;


~ TCP 四次挥手

四次挥手是为了终止连接; 这一过程由通信双方的任一方执行close来触发;

在这里插入图片描述

数据传输之后,双方都可释放连接;最开始的时候,双方都处于Established状态,假设客户端主动关闭,服务端被动关闭连接;

1、第一次挥手:客户端进程发送连接释放报文,并且停止发送数据,在该数据报的报头中,TCP Flags标志位的FIN=1,此时客户端的序列号seq=x,(x是关闭连接之前的Established状态下,数据最后一次发送时已经发送到服务端的数据的最后一个字节的序号+1),此时客户端就进入FIN-WAIT-1 终止等待1 的状态;TCP规定,即使SYN报文不携带任何数据,也会消耗一个序号;

2、第二次挥手:服务器收到报文之后,向客户端回复确认报文:ACK=1,ack=x+1,自己的序列号seq=y,此时服务端就进入Close-Wait关闭等待的状态;

TCP服务器通知高层应用进程客户端要释放跟服务器通信的连接了,这时会处于半关闭的状态,即客户端已经没有数据要发送了,但是如果服务端要发送数据,客户端还是能够接收的,这个状态还要持续一段时间,这个时间等于整个Close-Wait所持续的时间;

客户端收到第二次挥手 服务器向客户端发送的确认请求之后,就进入到Finish-Wait2 终止等待2 的状态;等待服务器发送释放连接报文,也就是第三次挥手的请求;因此这段时间内还有可能接收到服务器端发送的最后的数据;

3、第三次挥手:服务器向客户端发送完最后的数据之后,就会发送连接释放报文:FIN=1,ACK=1,ack=x+1,seq=z(在半关闭的状态服务器可能又发送了一些数据,假设此时的序列号变为了z);此时服务器就进入到了Last-ACK最后确认的状态,等待客户端的最后的确认;

4、第四次挥手:客户端在接收到服务端发送的连接释放报文之后,想服务端发送接收确认报文:ACK=1,seq=x+1,ack=z+1;此时客户端就进入了Time-Wait时间等待的状态;此时客户端的TCP连接还没有释放,必须等待2*MSL时间之后连接才真正释放,进入Close状态;服务端接收到客户端发送的确认报文之后 就立即进入到Close状态;

服务器关闭连接的时间要比客户端稍微早一点;

在这里插入图片描述

为什么会有Time-Wait状态(超时时间)

(1)确保对端有足够的时间收到ACK确认包;如果被动端关闭的一方没有收到ACK,就会触发重发FIN包;
(2)有足够的时间让这个连接不会和后面的连接混在一起,因为有些路由器会缓存IP数据包,如果连接不成功了,那么这些延迟收到的数据包 就有可能会跟新连接混在一起;

为什么需要四次挥手才能断开连接

TCP是全双工的,全双工允许通信双方同时传输数据,发送方和接收方都需要FIN报文和ACK报文,就是说双方各自需要两次挥手;

Linux服务器Socket通信时频繁出现大量Close-Wait状态的原因

问题的其中一个表现是 客户端一直在请求,但是返回给客户端的信息是异常的,服务端压根没有收到请求;

原因:在客户端发送FIN报文之后,服务端没有进一步发送ACK,或者FIN-ACK,在对方关闭连接后,服务器程序没有监测到,或者忙于读写操作,没有及时关闭连接;于是这个资源就一直被程序占用着;

遇到这种情况多数是因为程序中有bug,通常是因为某些连接没有及时释放导致的,或者某些配置,特别是处理请求的线程配置不合理;

解决:检查代码,特别是释放资源的代码;检查配置,特别是处理请求的线程配置;


>> UDP

~ UDP 报文结构

在这里插入图片描述

~ UDP 特点

1、面向无连接:传输数据之前,源端和终端没建立连接,在发送端,UDP传输数据的速度,仅仅是受应用程序生成数据的速度、计算机的能力、传输带宽的限制;在接收端,UDP把每个消息段放到队列中,应用程序每次从队列中读取一个消息段;

2、由于传输数据不建立连接,所以不需要维护连接状态,因此一台服务器可以同时向多个客户端发送相同的消息;

3、UDP数据包报文头部只有8个字节,相对于TCP的20个字节,额外开销小;

4、 UDP尽最大努力交付,不保证可靠交付;

5、UDP面向报文,不对应用程序提交的报文信息进行拆分或合并;

~ TCP 和 UDP 区别

TCP和UDP都是传输层的协议,TCP提供可靠的通信传输;

1、TCP面向连接,UDP面向无连接;

2、可靠性:TCP利用三次握手、确认和重传机制提供了可靠的传输,UDP传输可能会丢失数据包;

3、有序性:TCP利用序列号保证了数据包的顺序交付,到达可能无序,但是TCP会根据序列号进对数据包进行排序,UDP不具备有序性;

4、速度:TCP速度较慢,因为要创建连接,保证消息的有序性和可靠性,要做额外的很多事情;UDP传输速度快,适合对速度比较敏感的应用,比如在线视频 、电视广播、多人在线游戏等;

5、量级:TCP属于重量级的,UDP数据轻量级的,取决于数据报文头的大小,TCP20字节,UDP8字节;


>> HTTP

~ HTTP 特点

HTTP超文本传输协议,是一个基于请求与响应模式的、无状态的、应用层的协议;常基于TCP的连接方式;

1、支持客户端/服务器模式:HTTP协议工作与客户端/服务端架构之上,浏览器作为客户端通过URL向服务端web服务器发送请求,web服务器根据接收到的请求,向客户端发送响应信息;

2、简单快速:客户端向服务端请求服务的时候,只需传送请求方法(get、post、head)和路径即可;由于HTTP协议简单,使得HTTP服务器的程序规模小,所以通信速度快;

3、灵活:HTTP允许传输任意类型的数据对象;

4、无连接:每次连接只处理一个请求,服务器处理完客户端的请求,并收到客户的应答之后,就断开连接;这种方式可以节省传输时间;HTTP1.1默认使用长连接:服务器需要等待一定时间之后才断开连接;

5、无状态:协议对于事务处理没有记忆能力,缺少状态意味着如果后续处理需要前面的信息,则必须要被重传;这样会导致每次连接传输的数据量增大,服务器不需要先前的信息时,它的应答就比较快;


~ HTTP 请求报文结构

在这里插入图片描述


~ HTTP 响应报文结构

在这里插入图片描述


~ HTTP 协议简介

HTTP协议定义了Web客户端如何从Web服务器请求Web页面,以及服务器如何把Web页面传送给客户端;

HTTP采用了请求/响应模型,客户端向服务器发送一个请求报文,请求报文包含请求方法、URL、协议版本,请求头部,请求数据;服务器以一个状态行作为响应,响应内容包含协议版本,成功/错误代码,服务器信息,响应头部,响应数据;


~ HTTP请求/响应步骤

1、首先客户端连接到Web服务器:客户端通常是浏览器,与服务器的HTTP的端口(默认80)建立一个TCP套接字连接;

2、发送HTTP请求:通过TCP套接字,客户端向服务器发送一个文本的请求报文;

3、服务器接收请求并返回HTTP响应:服务器解析请求,定位请求资源,将资源副本写入到TCP套接字,由客户端读取;

4、释放连接TCP连接:若连接模式是,则服务器会主动关闭连接,客户端被动关闭连接;若连接模式是keep-live,则该连接会保持一段时间,在该时间内,服务器会继续接收请求;

5、客户端浏览器解析HTML内容;


~ 在浏览器地址栏键入URL,按下回车之后经历的流程

1、DNS解析:浏览器会依据URL,逐层查询DNS服务器缓存,解析URL中的域名所对应的IP地址;
DNS缓存从近到远依次是:浏览器缓存、系统缓存、路由器缓存、RPS服务器缓存、根域名缓存、顶级域名缓存;从哪级缓存查询到对应的IP则直接返回,不再查询后面的缓存;

2、TCP连接:解析到IP地址之后,会根据IP地址和端口(默认80),和服务器三次握手建立TCP连接;

3、浏览器发送HTTP请求到服务器;

4、服务器处理请求,并返回带有HTML文本的响应报文发送给客户端浏览器;

5、浏览器接收到响应的HTML,在窗口进行渲染;

6、浏览器四次挥手释放TCP连接;


~ HTTP 状态码

在这里插入图片描述

在这里插入图片描述


~ HTTP 请求的 GET 与 POST 方式的区别

1、get提交,提交的信息都封装到了请求消息的请求行中,会显示在地址栏中,对敏感的数据信息不安全,提交的信息数量有限,只能提交纯文本;
post提交,将提交的信息封装到了请求体中,不会在地址栏中显示,对敏感数据信息安全,可以提交大体积的数据,可以提交纯文本和二进制文件;

2、get一般用于从服务器上获取数据,post一般用于向服务器传送数据;

3、如果提交的信息中有中文,服务器默认会使用iso8859解码,会出现乱码,可以先使用iso8859对提交的消息编码,然后再指定中文码表进行解码;这种解决方法对get、post都有效,post还有一种解决方法,就是使用服务器端的request对象,调用它的setCharactorEncoding 方法,直接指定中文码表解码;

post:在web.xml中添加乱码过滤器,指定初始参数的encoding为utf-8;

4、在和服务器交互时,使用url方式使用get提交,使用超链接方式用get提交,使用表单方式get、post都可以,推荐使用post;

5、get可以被浏览器缓存,post不可以;


~ Session 与 cookie

网页之间是通过Http协议传输数据的,而Http是无状态的协议,也就是说一旦数据提交完后,浏览器和服务器的连接就会关闭,再次交互的时候需要重新建立新的连接;

http是无状态的,服务器无法确认用户的信息;为了解决这个问题,服务器会给每个访问服务器的用户发一个通行证,用户再次访问服务器的时候需要携带通行证,这样服务器就可以通过通行证确认用户的信息;

Cookie是客户端的通行证;是有服务器发送给客户端的特殊信息,以文本的形式存放在客户端;客户端每次向服务器发送请求 都会带上这些信息,cookie存放在HTTP请求头中;服务器接收到请求,会解析cookie,生成与客户端对应的内容;

Session是服务端的机制,在服务器上保存的信息;当服务器需要为客户端的请求创建session的时候,首先检查这个请求中是否包含了session标识:sessionID,如果有,说明以前已经为此客户端创建过session,服务器就按照sessionID检索出这个session直接使用,若客户端请求不包含sessionID,则创建一个session,并生成一个与此客户端相关的sessionID,然后在响应的时候,同响应数据发送给客户端进行保存;

Session实现方式:
(1)使用Cookie实现:服务器给每个session分配一个唯一的JSessionID,并通过Cookie发送给客户端,当客户端发起新的请求的时候,将在消息头中携带这个JSessionID,这样服务器就据此找到客户端对应的Session;

(2)使用URL回写来实现:服务器在发送给浏览器页面的所有连接中,都携带JSessionID的参数,这样客户端点击任何一个连接,都会把JSessionID带回服务器;如果直接在浏览器输入服务端资源的URL来请求该资源,Session是体会不到的;

Tomcat对Session的实现是同时使用Cookie和URL回写机制,如果发现客户端支持Cookie,就继续使用Cookie,停止使用URL回写,若Cookie被禁用,就使用URL回写机制;

Session 与 Cookie区别:
1、Coolie只能存储字符串,如果要存储非 ASCII码的字符串,还要对其编码;Session可以存储任何类型的数据;

2、Cookie存储在客户端浏览器上,对客户端是可见的,信息容易泄露,最好对Cookie加密;
Session存储在服务器,对客户端不可见,信息是安全的;

3、Session保存在服务器上,每个用户都会产生一个Session,如果并发访问的用户多,会消耗大量的内存,影响服务器的性能;
Cookie是保存在客户端的,不占服务器的资源;

4、如果浏览器禁用了Cookie,Cookie就没法用了;但是Session可以通过URL地址重写来进行会话追踪;


>> HTTPS

~ HTTPS 与 SSL/TLS

在这里插入图片描述
HTTP(Hypertext Transfer Protocol)超文本传输协议;
HTTPS(Hypertext Transfer Protocol over SecureSocket Layer),是以计算机网络安全通信为目标的传输协议;在HTTP下面加入了一个SSL层,从而具有了保护数据交换隐私、完整性、提供网站进行身份认证的功能;简单说就是安全版的HTTP;

SSL(Security Sockets Layer)安全套阶层;
1、是为网络通信提供安全及数据完整性的一种安全协议;
2、位于TCP与各应用层之间,是操作系统对外提供的API,SSL3.0以后更名为TLS;
3、采用身份认证和数据加密 来保证网络通信的安全和数据完整性;

在这里插入图片描述


~ HTTPS 数据传输流程

HTTPS在请求数据传输之前,会与服务器和web浏览器进行一次握手,在握手时确认双方的加密密码信息;

1、浏览器将支持的加密算法信息发送给服务器;

2、服务器会根据这些浏览器支持的加密方式,在自己支持的加密算法中选出一套加密算法和哈希算法,以证书的形式发送给浏览器;
证书包括证书发布的CA机构,证书的有效期,公钥,证书的所有者;

3、浏览器收到证书之后,首先验证证书的合法性,若证书受到浏览器信任,则会在浏览器地址栏会有标识显示,否则就会显示无效性的标识;证书验证之后,浏览器会结合证书随机生成一串密码,并使用证书中的公钥加密,之后使用约定好的哈希算法握手消息并生成随机数对消息进行加密,发送给服务器;

4、服务器接收浏览器发送的数据后,使用私钥解密信息,确定密码,通过密码解密web浏览器发送过来的握手信息,验证哈希是否与web浏览器一致,然后服务器会使用密码加密新的握手信息发送给浏览器;

5、浏览器解密并计算经过哈希算法加密过的握手消息,如果与服务器发送过来的哈希值一致,则此握手过程结束后,服务器与浏览器会使用之前浏览器生成的随机密码和对称加密算法进行加密,然后交换数据;


~ HTTP 和 HTTPS 的区别

HTTPS = HTTP + 加密 + 认证 + 完整性保护

1、HTTPS协议需要都CA申请证书(收费),HTTP不需要;

2、HTTPS密文传输数据,HTTP明文传输数据;

3、连接方式不同;HTTPS默认使用443端口,HTTP默认80端口;

4、HTTP连接无状态,HTTPS有状态;


Socket

~ Socket 简介

连个进程若要进行通信,最基本的一个前提就是能唯一标识一个进程;在本地进程通信中,可以使用PID号唯一标识一个进程,但PID只在本地唯一;

IP层的IP地址可以唯一标识一台主机,TCP协议和端口号可以唯一标识主机中的一个进程,所以可以使用TCP协议+IP地址+端口号作为唯一标识来标识网络中的一个进程;这种唯一标识模式称为套接字Socket


~ Socket 通信流程

在这里插入图片描述

1、服务器创建Socket, 然后为Socket绑定IP地址和端口号;
2、服务器的Socket监听该端口号的请求,随时准备接收客户端发来的连接;这时服务器的Socket只是监听,并未打开连接;
3、 客户端创建Socket,然后打开Socket连接,并根据服务器的IP地址+端口号,尝试去连接服务器的Socket;
4、服务器Socket接收到客户端的Socket请求,被动打开,开始接收客户端的请求,直到客户端返回连接的信息,这时服务器的Socket就进入到阻塞状态,一直等待客户端返回连接信息之后,才返回,同时开始接收下一个客户端的连接请求;
5、客户端在连接成功之后,就会想服务器发送连接状态信息,服务端接收客户端的连接信息之后,就会将accept方法返回,连接成功,之后客户端就可以向Socket中写入信息了;服务器就能收到并读取相关信息;
6、发送完信息之后,客户端就会关闭Socket,服务端也需要关闭Socket;


~ 面试题

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值