讲讲OSI协议
应用层:为应用程序间提供通信和交互的协议,比如DNS,HTTP
传输层:为两台主机中的进程提供通用的数据传输服务,为应用层把报文封装成TCP报文段或者UDP用户数据进行传送,比如TCP和UDP
网络层:为两台主机提供通信服务,为传输层产生的报文段或用户数据报封装成IP数据报进行传送,协议为ARP,ICMP
数据链路层:为两台主机之间的数据传输提供服务,两台主机之间的传输,总是在一段一段的链路上传送的,这就需要链路层协议,为网络层把IP数据包封装成帧,在链路上进行传递,协议为CSMA,PPP
物理层:在传输媒体上进行传输比特流,尽可能的为数据链路层屏蔽传输媒体和通信手段的差异,把帧拆分成比特流在传输媒介上进行传输,原则有时分复用,频分,码多分址等
DNS协议
域名解析协议,提供了域名和IP地址之间相互转换的服务
可以使用UDP或者TCP,但一般用UDP,因为快,只有一个请求,一个应答就可以了,但是UDP的传输内容不能超过512字节,一般上客户端向DNS服务器查域名,返回内容都不超过512字节,所以UDP够用了
为什么区域传送使用TCP
区域传送是主DNS服务器上的数据有变化了,需要向下传送变化的那份数据时,因为数据必然很大,并且要保证传输可靠,所以不能使用UDP,因为DNS是分布式数据库,主DNS复制内容的时候,不能用不可靠的UDP,需要使用TCP协议
DHCP协议
给用户提供了即插即用的联网方式,用户不再需要手动配置IP地址等信息,其自动为用户配置IP地址,子网掩码以及网关等信息
应用层还有没有别的协议?
FTP:动态主机配置协议
SMTP:电子邮件协议
Web页面请求过程
- URL在敲下之后,首先在浏览器会生成一个TCP套接字,以向目标HTTP服务器请求资源,为了生成该套接字,需要知道URL域名对应的IP地址,而为了向DNS服务器发送请求,生成一个DNS查询报文
- 这个DNS数据报被放入一个目的地址为DNS服务器IP地址的IP数据报中,IP数据报进而被放入到一个帧中,接下来该把这个帧发送到默认网关
- 为了知道网关的MAC地址,必须使用ARP协议进行解析出下一跳
- 网关路由器拿到了DNS查询报文之后,会根据报文转发给下一跳,直到到达DNS服务器
- 到达DNS服务器之后,DNS在数据库中查找准备解析的域名,找到记录之后,发送DNS回答报文,放入UDP报文段,转发返回主机
- 在生成套接字之前必须与HTTP服务器进行三次握手来建立连接,生成一个具有目的端口80的TCP SYN报文段,并且向HTTP服务器发送该报文段,HTTP服务器收到该报文段之后,回复TCP的SYN ACK报文段发回主机,主机接收到SYN ACK之后再回复一个ACK确认连接报文段到HTTP服务器,三次连接建立完毕
- 主机拿到了解析后的域名,也就是IP地址后,就能生成套接字,把套接字用于向WEB服务器发送HTTP GET报文
- HTTP服务器从TCP套接字读取HTTP GET报文,生成一个响应报文,把Web页面的内容放入报文主体中,返回给主机
- 浏览器拿到响应报文后,抽取Web页面内容,渲染页面
浏览器解析域名,会先查看本机的hosts文件,如果有就使用hosts文件里的ip地址,如果没有就发送一个DNS请求到本地的DNS服务器,请求到达本地DNS服务器之后,会先查找缓存记录,如果缓存没有就向DNS根服务器进行查询,根服务器没有保存具体的映射关系,而是告诉本地DNS服务器,你可以去域服务器上继续查找,去域服务器查找的过程是一个迭代的过程(对于不同等级的域名),于是本地DNS服务器继续向域服务器发出请求,域服务器也不会返回映射关系,而是告诉本地DNS服务器域名的解析服务器地址,最后DNS服务器向域名解析服务器发送请求,终于能收到一个域名和IP地址的对应关系.该映射关系返回后会被本地DNS服务器缓存
?HTTP状态码
- 1.2开头的都表示成功
- 3开头表示重定向
- 4开头表示客户端请求错误,比如404没找到资源
- 5开头表示服务器错误
HTTP长连接和短连接讲讲,流水线是什么?
长短连接:当浏览器访问一个包含多张图片的网站,如果用短连接就会建立大量的tcp连接,这样很消耗资源,长链接只允许建立一个TCP连接,就能进行多次HTTP通信,1.1之前默认短连接,1.1之后默认长连接
流水线:默认情况下HTTP请求是按照顺序发的,下一个请求只有在当前请求收到响应之后才会被发出,流水线就是在一个HTTP长链接下连续发出请求,不用等待响应返回,减少延迟
Cookie和Session的区别?
Cookie是保存在客户端浏览器里的一种信息载体,用来保存一些站点的用户数据,这样能为用户定制一些功能比如免登录服务,服务器发送的响应报文的首部有一个set-cookie的字段,客户端在拿到这个响应后把这个字段内容保存到浏览器中,在客户端再次发送请求同类资源的时候,就会把ookie一起携带在请求中,发送到服务端
Session是保存在服务器中的信息载体,存储在浏览器的cookie并不安全,session则相对于比较安全,如果使用session维护用户登录状态:
- 在登录时,把用户名,密码表单,放入http请求报文中
- 服务器收到之后创建一个session,并且创建一个名为sessionID的cookie,其值就映射了服务器里的session
- 客户端收到这个cookie之后,把sessionid保存在cookie里
- 客户端之后对同一个服务器进行请求的时候,会把cookie也带上去,服务器收到之后提取出sessionID,从中读取出用户信息
如果禁用了Cookie可以使用URL重写,把sessionID作为URL的参数进行传递
HTTP1.1和1.0的主要区别
长链接和短连接,http1.1增加了一些错误状态码
请求转发和重定向的区别
请求转发:
- 浏览器只发出一次请求,收到一次响应
- 请求所转发的资源中可以直接获取到请求中所携带的数据
- 浏览器地址栏显示的为用户所提交的路径,不会改变
- 只能跳转到当前应用的资源中
重定向:
- 浏览器发出两次请求,收到两次响应
- 重定向到的资源不能直接获取到用户提交请求中所携带的数据
- 浏览器地址栏显示的为重定向的请求路径,而非用户提交请求的路径,也正应为如此,重定向的一个很重要的作用是防止表单的重复提交
- 重定向不仅可以跳转到当前应用的其他资源,也可以跳转到其他应用中的资源
如何选择:一般选择转发,重定向有以下两种场景
- 如果需要跳转到其他应用
- 如果处理表单数据的servelet需要跳转到其他的servlet,则需要选择重定向,防止表单重复提交
URL和URI的区别
URI像是一个身份证,是资源的标志符
URL像是一个地址,是资源的定位符,一个URL可以确定哪个主机的哪个项目下的哪个资源,URL是URI的子集,但是在万维网中URL也充当了URI的角色,只要知道了URL就知道了头衔+定位
HTTP和HTTPS的区别
端口来讲:http默认为80,HTTPS为443
安全性来讲:后者高于前者.前者运行于TCP之上,所有的传输都是明文传输,客户端和服务端无法验证对方的身份,后者在中间加了一层SSL协议,SSL协议是运行于TCP之上的,所有的传输内容都经过了加密,这个加密其实是对称加密,而对称密匙是用服务器方的公钥进行了非对称加密传输过去的
对称加密算法:加密解密为同一个密匙,速度快
非对称加密:密匙和成对出现,公钥加密,私钥解密,或者公钥解密,私钥加密,算法复杂,消耗资源更多
?SSL过程
SSL是安全套接字,是用于加密和验证应用程序和web服务器之间发送数据的协议,用于提供身份验证,HTTPS里的S指的就是SSL
简略过程如下:
- 首先客户端向服务器发起ssl连接请求
- 服务器把自己的证书发给客户端浏览器
- 客户端浏览器检查服务器发送的证书是不是CA签发的,如果是就继续执行协议,如果不是就发出一个警告,询问是否继续
- 浏览器从证书中拿到公钥,用公钥加密通信用的对称密钥发给服务器
- 服务器用自己的私钥对其进行解密,拿到对称密钥
- 接下里就可以进行数据传输,服务器和客户端双方使用对称秘钥对数据进行加密,可以保证安全
怎么保证不被篡改?
可以把摘要(md5)单独加密发过去,解密的时候对内容进行md5算法,和摘要对比,如果不一样了就是被篡改了
怎么保证公钥就是服务器的公钥?
服务器事先已经向ca申请,ca是大家都信任的机构,ca在判明申请者的身份之后,会用自己的私钥对服务齐全的公开密匙进行加密,也就是做了一个数字签名,然后把这个经过数字签名之后的证书一起发给客户端,客户端拿到之后用数字签名进行验证,如果验证过了,就可以开始通信了
单独的非对称加密的弱点在于公钥可能被伪造,比如a和b通信,中间隔了一个c,这个c把a,b通信时的公钥全部都换了,这样也是没法验证身份的,那只要保证公钥不被伪造就可以了,ca的公钥大家都相信,甚至已经内置在浏览器里,不会被伪造,都相信ca所以只要数字签名认证通过了,就可以完全信任服务器了
Get和Post的区别
get把请求的数据放在url上,以?分割和传输数据,参数之间以&相连,post把数据放在请求体中
get提交数据最大为2k(受限于浏览器),post理论没有限制
get产生一个tcp数据包,浏览器会把http header和data一并发送出去,服务器响应200返回数据,post产生两个tcp数据包,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200返回数据
get请求是幂等的,会被浏览器主动缓存,post不是幂等的,不会被浏览器主动缓存,除非手动设置
TCP三次握手
- SYN：请求连接标志位
- ACK：确认标志位
- seq：序号
- ack：确认号
过程:
- 客户端的连接请求:客户端发送一个带有SYN标志位的连接请求到服务器,客户端计入到SYN-SENT状态
- 服务端连接确认请求:服务器收到之后回复一个SYN和ACK确认报文到客户端,此时服务端进入SYN-RECV状态,等待三次握手
- 客户端的连接确认请求:客户端收到确认报文之后,向服务器再次发出带ACK的确认报文,后客户端这边连接建立,服务端收到客户端的第三次确认报文后连接确立
为什么要三次握手?
- 通信时双方的行为,双方都需要确认自身的接受和发送是否正常以及对方的就收发送是否正常,如果只有两次,服务端是没有办法确认自己发送和对方接收是否正常
- 防止失效连接到达服务器后重新打开连接,客户端发送的请求如果阻塞,那么客户端等待一个超时重传时间以后,会重发一个连接请求,假设这个来迟滞留的连接最终到达了服务器,不进行三次握手的话,服务器就会打开两个连接,如果有三次握手,客户端就会忽略掉服务器之后的连接确认请求
如果1,2,3次握手分别丢包?
- 第一次客户端发送的SYN包丢了:客户端接不到响应,超时重传
- 第二次服务端发的SYN和ACK包丢了,客户端接不到响应,超时重传
- 第三次客户端发的ACK丢了,因为第三次发送完ACK之后,随时接下来会继续往服务端发送数据,发数据的时候会带上ACK,所以说客户端响应的ACK包丢了,服务器也能够通过后来的包来建立连接
- 第三次故意不发送ACK,服务器在等待第三次握手的时候处于半连接的状态,也是需要消耗资源的,如果攻击者故意不发送第三次ACK,让大量的连接处于半连接状态,那么会把服务器的资源耗尽,洪水攻击的目的就达到了-->可以通过缩短SYN报文的time out时间,设置一个Cookie,如果短时间收到同一个IP的重复报文就直接丢弃
TCP四次挥手?
过程:
- 客户端发送一个FIN标志位的关闭连接请求,此时客户端进入FIN-WAIT-1状态
- 服务器收到该请求,回复一个ACK
- 客户端收到ACK的时候,进入FIN-WAIT-2状态,此时处于半关闭状态,服务器能给客户端发消息,但是客户端不能给服务器发消息
- 当服务器把剩下的消息发完之后,会发送一个带FIN标志位的关闭连接,(也带有ack)请求给客户端
- 客户端收到请求后,发出ACK确认,并且进入最后的TIME-WAIT状态,等待2MSL(最大报文存活时间)后释放连接
- 服务端收到确认之后,释放连接
四次挥手的原因
服务端在收到客户端的fin包之后,表示客户端不再发送数据了,但客户端还可以接收数据,而服务端也不是说数据都发完了,所以服务端可以立即关闭,也可以再发送一段时间数据之后再发送给FIN报文给客户端表示同一关闭,因此服务端的ACK和FIn标志位会分开发送
为什么要等待2MSL?
确保最后一个报文能到达,如果服务器没收到来自客户端的ack报文,就会重写发送fin报文到客户端,客户端等待一段时间就是为了处理这种延迟的情况,等待时间为2MSL是为了让本连接持续时间的所有报文从网络中消失,使得下一个连接不会出现旧报文
挥手四次分别丢包?
- 断开连接的fin包掉了,客户端在没有收到服务端的回复,进行超时重传
- 服务端回复的ack丢了:客户端没有收到服务端回复,进行超时重传
- 服务端发送的fin,ack丢了:服务端在超时后会重传,,此时客户端有两种情况第一是处于FIN-WAIT-2状态(之前的ack也丢了),要么一致处于TIME-WAIT状态,等待2MSL,这个等待时间中如果重新收到了FIN,ACK包,也会回复一个ACK应答服务端,并且做自己的状态转换
- 客户端最后回复的ACK丢了:客户端开始2MSL的等待时间,服务端因为没有收到ACK的回复,会重试一段时间,知道服务端重试超时后主动断开连接,或者等到新客户端接入后,收到服务端重试的FIN消息后,回复RST消息,服务端在收到RST消息后,复位服务端状态
- 客户端收到ACK,服务端跑路了:客户端在收到ACK后,进入了FIN-WAIT-2状态,等待服务端的fin包,但服务端跑了,这个包永远等不到了,TCP中没有对这个状态的处理机制,也就是说协议是不管的,但是操作系统会管,在LINUX下,就可以通过tcp_fin_timeout,来对这个状态设定一个超时时间,当有这个限制以后,客户端并不会切换到TIME-WAIT状态,而是直接进入CLOSED状态
- 客户端收到ACK后,客户端自己跑了:客户端收到ack后跑路,服务端后续在发送FIN,ACK就会没有回复,会不断的走TCP超时重试机制,服务端处于LAST-ACK状态,有两种情况可能发生:在超时一定时间后服务器主动断开,收到RST后主动断开连接(RST是一个重置消息,表示前面错误率,应该回到初始化状态)
TCP如何保证可靠传输
可靠传输的基础是滑动窗口协议,配合着一些其他的控制来使得整个过程可靠,这些控制分为三组去解释:基本控制,发送端的控制,接收端的控制
滑动窗口:
- 首先在发送方和接收方都维护一个滑动窗口,发送方的窗口大小其实是由接收方响应报文里的一个字段控制的
- 发送方:窗内都允许发送,窗内最左侧字节如果已经发送并且确认,向右滑动,,直到第一个不被确认状态的字节停下
- 接收方:窗内都允许被接收,窗内最左侧的字节如果已经接收,向右滑动到第一个不是已经接收的状态的字节,并且最重要的是,接收方仅仅对最后一个按序到达的字节进行确认
基本的控制:
- 把应用层的数据拆分成适合传输的一个个块
- 把发送的每一个块进行编号,在接收端对数据包进行重排
发送端的控制:
- 超时重传:当发送方发送一个包,启动一个定时器,等待确认这个包,如果不能在阈值内收到确认这个包,重发
- 流量控制:为了控制发送方发送速率,保证接收方来得及接收,接收端返回的确认报文中的窗口字段可以控制发送窗口大小,从而影响发送方的速率,将窗口字段设置为0,则不能发送数据
- 拥塞控制:当网络拥堵的时候,会丢包,此时发送方会不断的重传,从而导致拥塞程度更高,因此出现拥堵的时候,应当限制发送方的发送速率;流量控制主要是端对端的控制,要做的是抑制发送端发送的速率,为了控制双方来的及接收,拥塞控制是为了宏观上降低网络的拥塞程度
接收端的控制:
- 校验和:保证首部的数据的校验和,如果校验和有误就丢弃该数据包,且不发送确认消息
- 丢弃重复:如果收到重复的数据包就直接丢弃
UDP协议讲一讲
UDP协议是面向无连接的,尽最大可能交付,没有拥塞控制,直接把应用层的报文拿下来,然后价格UDP首部就算结束了,支持一对一,一对多,多对一,多对多的通信
TCP协议是面向连接的,提供可靠交付,有超时重传,流量控制,拥塞控制等保证可靠连接的一些机制,把应用层传下来的数据看成字节流,拆分成最适合传输的大小,封装成报文段来传输,每条TCP连接只能是一对一的
如何设计一个可靠的UDP协议?
数据完整性->添加验证CRC(循环冗余检查)字段
乱序到达->加上一个数据包序列号seq
丢包->确认和重传机制
TCP和UDP的应用场景
实时音视频使用UDP,一方面它常常设计到网络穿透,另一方面它不需要重传,重传会导致延迟和不同步,如果某一帧重传导致了0.5秒后才到达,那么整个音频就延迟了0.5秒
如果出现卡顿掉帧就是UDP的结果,如果是TCP协议,直接是视频黑掉,然后重新又有了
讲讲ARP协议
提供了由目的IP地址得到MAC地址的功能
在同一个局域网中:主机a想给b发信息,会先在自己的ARP缓存表中找到是否有对应主机的ip地址,如果没有,则会广播ARP请求分组,主机b和主机a在同一个局域网,则主机b收到ARP分组的时候,会回复一个ARP响应分组,里面带有自己的MAC地址
不在同一个局域网:主机A先把子网掩码和目的IP进行相与操作,发现不在一个网段,那么下一跳就去找默认的网关,如果ARP缓存没有默认网关的MAC地址,也需要先发一个ARP请求分组,等默认网关给他回一个ARP响应分组后,就拿到了网关的MAC地址
讲讲ICMP协议?
本质还是个IP数据报,是网络层的协议,IP数据报的数据段使用ICMP报文代替了而已
其作用是提高交付成功机会,让网络节点能报告差错情况和异常情况
MAC地址是什么?为什么有了MAC还需要IP地址呢?
MAC又称物理地址,物理地址是数据链路层和物理层使用的地址,IP地址是网络层及以上层使用的地址
需要使用两个地址是由组网方式决定的,如今比较流行的Internet方式是把主机通过局域网组织在一起,然后通过交换机和Internet相连接,由于IP只是逻辑上标识,任何人都可以随意修改,因此不能用来标识用户,MAC地址则是固化在网卡里的,理论上讲无法冒名顶替;如果只有MAC地址的话,只有在同一网络区域内才可以进行数据传输;类似的IP地址相当于包裹地址,MAC地址相当于收件人信息,如果只知道收件人信息,除非送快递的人认识你,不然就收不到
什么是子网掩码?
子网掩码用来表明一个IP地址所标示的主机是处于哪个子网中的,子网掩码不能单独存在,必须结合IP地址一起使用,它只有一个作用就是将某个IP地址划分成网络地址和主机地址两部分;子网掩码和具体的IP做位与运算后会将IP地址的后8位淹没掉(主机码),如果经过掩码处理后网络码一致,就可以进行正常通信,否则不能