计算机网络
OSI TCP/IP
OSI(Open System Interconnect)七层协议模型
各层功能
- 物理层: 通过媒介传输比特,确定机械及电气规范,传输单位为bit,主要包括的协议为:IEE802.3 CLOCK RJ45
- 数据链路层: 将比特组装成帧和点到点的传递,传输单位为帧,主要包括的协议为MAC VLAN PPP ARP
- 网络层:实现数据包的选路和转发,提供网络互连,传输单位为包,主要包括的协议为IP ICMP
- 传输层:为两台主机上的应用程序提供端到端(end to end)的通信,传输单位为报文,主要包括的协议为TCP UDP
- 会话层:建立、管理和终止会话,传输单位为SPDU,主要包括的协议为RPC NFS
- 表示层: 对数据进行翻译、加密和压缩,传输单位为PPDU,主要包括的协议为JPEG ASII
- 应用层: 各种应用软件(应用程序及接口),传输单位为APDU,主要包括的协议为 FTP HTTP DNS
TCP/IP 体系结构
应用层
HTTP:超文本传输协议,在浏览器与服务器间传送文档。
DNS(Domain Name Service,域名服务)协议提供机器域名到IP地址的转换。DNS是一套分布式的域名服务系统。每个DNS服务器上都存放着大量的机器名和IP地址的映射,并且是动态更新的。众多网络客户端程序都使用DNS协议来向DNS服务器查询目标主机的IP地址。(UDP传输)
SMTP协议:简单邮件传送协议
FTP协议:文件传输协议
RIP 协议:距离矢量路由选择协议。
传输层
TCP协议(Transmission Control Protocol,传输控制协议)为应用层提供可靠的、面向连接的和基于流(stream)的服务。
UDP协议(User Datagram Protocol,用户数据报协议)则与TCP协议完全相反,它为应用层提供不可靠、无连接和基于数据报的服务。
网络层
IP协议:IP协议根据数据包的目的IP地址来决定如何投递它,使用逐跳(hop by hop)的方式确定通信路径。(1) 寻址。(2) 路由选择。(3) 分段与组装。
ICMP协议:是IP协议的重要补充,主要用于检测网络连接。(ping工作协议)
数据链路层
ARP协议:ARP地址解析协议用于将计算机的网络地址(IP地址32位)转化为物理地址(MAC地址48位)
原理:
- 主机A检查自己的ARP缓存表(ARP cache),其中存储了最近与其他主机通信的IP地址和对应的MAC地址。如果目标主机的IP地址已经存在于ARP缓存表中,主机A可以直接使用该MAC地址发送数据。
- 如果ARP缓存表中没有目标主机的IP地址条目,主机A将发送一个ARP请求广播到局域网上的所有主机。ARP请求包含主机A的IP地址和MAC地址,以及目标主机的IP地址。
- 其他主机收到ARP请求后,会检查自己的IP地址是否与ARP请求中的目标IP地址匹配。如果匹配,说明该主机是目标主机,它将发送一个ARP响应给主机A,包含自己的IP地址和MAC地址。
- 主机A收到ARP响应后,将目标主机的IP地址和MAC地址存储到ARP缓存表中,以便将来的通信使用。
- 主机A现在知道了目标主机的MAC地址,可以使用该地址发送数据包到目标主机。
RARP协议:RARP协议(Reverse ARP,反向ARP协议),其功能是将MAC地址解析为对应的IP地址。
TCP UDP
UDP头部结构
- 源端口:16位表示取值范围是1-65535。
- 目的端口:也是16位。
- 长度:长度是16位表示,指udp数据包的整体长度,udp数据包最小是8个字节,所以它能发送的最大负载长度是65535-8。
- 校验和:udp的校验和用16位表示,是检验协议头和负载数据。
TCP头部结构
32位序号(sequence number):一次TCP通信(从TCP连接建立到断开)过程中某一个传输方向上的字节流的每个字节的编号。序号值被系统初始化为某个随机值ISN(Initial Sequence Number,初始序号值)。
32位确认号(acknowledgement number):用作对另一方发送来的TCP报文段的响应。其值是收到的TCP报文段的序号值加1。
4位头部长度(header length):标识该TCP头部有多少个32bit字(4字节)。
标识位:
- URG标志,表示紧急指针(urgent pointer)是否有效。
- ACK标志,表示确认号是否有效。称携带ACK标志的TCP报文段为确认报文段。
- PSH标志,提示接收端应用程序应该立即从TCP接收缓冲区中读走数据,为接收后续数据腾出空间。
- RST标志,表示要求对方重新建立连接。称携带RST标志的TCP报文段为复位报文段。
- SYN标志,表示请求建立一个连接。称携带SYN标志的TCP报文段为同步报文段。
- FIN标志,表示通知对方本端要关闭连接了。称携带FIN标志的TCP报文段为结束报文段。
16位窗口大小(window size):是TCP流量控制的一个手段。这里说的窗口,指的是接收通告窗口(Receiver Window,RWND)。
16位校验和(TCP checksum):由发送端填充,接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。
16位紧急指针(urgent pointer):是一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。
选项字段40字节:最大报文段长度(Max Segment Size,MSS),通常将MSS设置为(MTU-40)字节,(减掉的这40字节包括20字节的 TCP头部和20字节的IP头部),MTU为帧的最大传输单元。对以太网而言,MSS值是 1460(1500-40)字节。
RST 产生复位报文段的3种情况:
- 访问不存在的端口
- 异常终止连接
- 处理半打开连接
TCP与UDP区别?
(1)连接:
- TCP 是面向连接的传输层协议,即传输数据之前必须先建立好连接。
- UDP是无连接的。
(2)服务对象:
- TCP 是点对点的两点间服务,即一条 TCP 连接只能有两个端点;
- UDP 支持一对一,一对多,多对一,多对多的交互通信。
(3)可靠性:
- TCP 是可靠交付:无差错,不丢失,不重复,按序到达。
- UDP 是尽最大努力交付,不保证可靠交付。
(4)拥塞控制,流量控制:
TCP 有拥塞控制和流量控制保证数据传输的安全性。
UDP 没有拥塞控制,网络拥塞不会影响源主机的发送效率。
(5) 报文长度:
- TCP 是动态报文长度,即 TCP 报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的。
- UDP 面向报文,不合并,不拆分,保留上面传下来报文的边界。
(6)首部开销:
- TCP 首部开销大,首部 20 个字节。
- UDP 首部开销小,8 字节。(源端口,目的端口,数据长度,校验和)
(7)TCP传输速度比UDP慢,TCP是重量级协议、UDP是轻量级协议
TCP建立(三次握手)
- Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,等待Server确认。此时客户端进入SYN-SENT(同步已发送) 状态。
- SYN报文段(即SYN=1的报文段)不能携带数据,但要消耗一个序号
- Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置1,ack=J+1,随机产生一个值seq=K,并将该数据包发给Client以确认连接请求。这时TCP服务器进行进入SYN-RCVD(同步收到)状态。
- 同理,此报文段也不能携带数据。
Client收到确认后,检测ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给Server。完成三次握手,客户端进入ESTABLISHED(已建立连接)状态。当服务器收到客户端的确认后,也进入ESTABLISHED(已建立连接)状态。
- TCP标准规定,ACK报文段可以携带数据,但如果不携带数据则不消耗序号
ISN(Initial Sequence Number)初始序号是动态生成的。
TCP关闭(四次挥手)
客户端向服务器发送一个FIN报文,首部的FIN=1,同时报文给自己指定一个序号(m),此时客户端进入FIN_WAIT_1 (终止等待1)状态,但客户端依然可以接收服务器发送来的数据。
- TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
服务端收到了客户端的FIN报文,会发送ACK报文进行确认,把收到报文的序列号的值+1(m+1)作为ACK报文的序列号的值,表明已经收到了客户端的报文,服务器进入CLOSE-WAIT(关闭等待)状态
- TCP服务器进程这时应通知高层应用程序,客户端到服务端这个方向的连接就释放了,此时TCP连接处于半关闭(HALF-CLOSE)状态,即客户端已经没有数据要发送了,但服务器若发送数据,客户端仍要接收。客户端收到服务端的确认后,进入FIN-WAIT-2(终止等待2)状态。等待服务端发出的连接释放报文段。
当服务器没有数据要发送了,也想要断开连接,会给客户端发送FIN报文,且指定一个序列号(n),服务器进入了LAST-ACK(最后确认)状态。
客户端收到FIN之后,一样会发送一个ACK报文作为应答,且把服务端的序号+1(n+1)作为自己ACK报文的序号。然后进入TIME-WAIT(时间等待)状态,等待2MSL(MSL:报文段最大生存时间),然后关闭连接。
两次握手不可以:
- TCP 是全双工通信,两次握手只能确定单向数据链路是可以通信的,并不能保证反向的通信正常
详细解释:
这个问题的本质是:在信道不可靠的情况下, 通信双发需要就某个问题达成一致. 需要几次通信?
对于此问题,无论在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的
具体来说:
- TCP连接的双方要确保各自的收发消息的能力都是正常的。
- 客户端第一次发送握手消息到服务端,服务端接收到握手消息后把ack和自己的syn一同发送给客户端,这是第二次握手,当客户端接收到服务端发送来的第二次握手消息后,客户端可以确认“服务端的收发能力OK,客户端的收发能力OK”,但是服务端只能确认“客户端的发送OK,服务端的接收OK”,
- 所以还需要第三次握手,客户端收到服务端的第二次握手消息后,发起第三次握手消息,服务端收到客户端发送的第三次握手消息后,就能够确定“服务端的发送OK,客户端的接收OK”,
- 至此,客户端和服务端都能够确认自己和对方的收发能力OK,TCP连接建立完成。
四次挥手的原因?
因为当处于LISTEN状态的服务器端收到来自客户端的SYN报文(客户端希望新建一个TCP连接)时,它可以把ACK(确认应答)和SYN(同步序号)放在同一个报文里来发送给客户端。但在关闭TCP连接时,当收到对方的FIN报文时,对方仅仅表示对方已经没有数据发送给你了,但是自身可能还有数据需要发送给对方,则等你发送完剩余的数据给对方之后,再发送FIN报文给对方来表示你数据已经发送完毕,并请求关闭连接,所以通常情况下,这里的ACK报文和FIN报文都是分开发送的。
TIME_WAIT的作用
2MSL(MaximumSegment Life,报文段最大生存时间)
- 保证最后一次握手报文能到服务器,能进行超时重传。
- 2MSL 后,这次连接的所有报文都会消失,不会影响下一次连接。
缺点:
- 第一是内存资源占用,但不是很严重,基本可以忽略。
- 第二是对端口资源的占用,一个 TCP 连接至少消耗一个本地端口。端口资源也是有限的,一般可以开启的端口为 32768~61000 ,也可以通过net.ipv4.ip_local_port_range指定,如果 TIME_WAIT 状态过多,会导致无法创建新连接。
TCP状态转移图
TCP的可靠机制
TCP超时重传
TCP可靠性中最重要的一个机制是处理数据超时和重传。TCP协议要求在发送端每发送一个报文段,就启动一个定时器并等待确认信息;接收端成功接收新数据后返回确认信息。若在定时器超时前数据未能被确认,TCP就认为报文段中的数据已丢失或损坏,需要对报文段中的数据重新组织和重传。
拥塞控制
包含四个部分慢启动(slow start)、拥塞避免(congestion avoidance)、快速重传(fast retransmit)和快速恢复(fast recovery)
SWND(Send Window,发送窗口 )、SMSS(Sender Maximum SegmentSize,发送者最大段大小)、接收通告窗口(RWND)、拥塞窗口(CongestionWindow,CWND)
慢启动:CWND将按照指数形式扩大。慢启动算法的理由是,TCP模块刚开始发送数据时并不知道网络的实际情况,需要用一种试探的方式平滑地增加CWND的大小。(cwnd *2)
拥塞避免:慢启动门限(slow start threshold size,ssthresh)。当CWND的大小超过该值时(一般设为65536),TCP拥塞控制将进入拥塞避免阶段,拥塞窗口的值不再指数上升,而是加法增加。(cwnd +1)
快速恢复:当发送方知道只是丢失了个别的报文段,不会启动慢开始算法,而是执行快恢复算法。将阈值设为当前窗口大小的一半,同时设置拥塞窗口为阈值的大小,然后执行拥塞避免算法。
快速重传:发送方只要一连收到3个重复确认,就知道接收方没有收到应当立即进行快重传,这样就不会出现超时。
如何判断拥塞?
- 传输超时,或者说TCP重传定时器溢出。采用慢启动和拥塞避免
- 接收到重复的确认报文段。采用快速重传和快速恢复
TCP 粘包/拆包 怎么解决?
一个完整的数据包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这个就是TCP的拆包和粘包问题。
原因
1、应用程序写入数据的字节大小大于套接字发送缓冲区的大小.
2、进行MSS大小的TCP分段。( MSS=TCP报文段长度-TCP首部长度)
3、以太网的payload大于MTU进行IP分片。( MTU指:一种通信协议的某一层上面所能通过的最大数据包大小。)
怎么解决
1、消息定长
2、在包尾部增加回车或者空格符等特殊字符进行分割
3、将消息分为消息头和消息尾,在头部中保存有当前整个消息的长度,只有在读取到足够长度的消息之后才算是读到了一个完整的消息
4、使用其它复杂的协议,如RTMP协议等
为什么UDP不粘包?
对于UDP,不会使用块的合并优化算法,不存在封包,再加上UDP本身是一个“数据包“协议,也就是两段数据是有界限的(保护消息边界:指传输协议把数据当做一条独立的消息在网上传输,接收端一次只能接受一条独立的消息)。从TCP和UDP的头部结构体就可以很明显的看到,UDP头部是记录了数据的长度的,而TCP头部里面并没有记录数据长度的变量。
HTTP
HTTP 协议是 Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网(WWW:World Wide Web)服务器传输超文本到本地浏览器的传送协议。
HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文,请求报文包含请求行(请求的方法、URL、协议版本)、请求头部和请求数据。服务器以一个状态行作为响应,响应的内容包括状态行(协议的版本、成功或者错误代码、服务器信息)、响应头部和响应数据。
在浏览器输入URL地址到显示主页的过程(HTTP请求过程)?
大概过程:
(1)浏览器向DNS 服务器请求解析该URL 中的域名所对应的IP 地址; (2)解析出IP 地址后,根据该IP 地址和默认端口80,和服务器建立TCP 连接; (3)浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求,该请求报文作为TCP 三次握手的第三个报文的数据发送给服务器; (4)服务器对浏览器请求作出响应,并把对应的html 文本发送给浏览器; (5)释放TCP 连接; (6)浏览器将该html 文本解析后显示网页内容;
细致过程(笔试原题,排序):
1、浏览器输入URL,先解析URL地址是否合法
2、浏览器检查是否有缓存(浏览器缓存 - 系统缓存 - 路由器缓存)。如果有,直接显示。没有,进行(3)
3、在发送HTTP请求前,需要域名解析(DNS解析),解析获取对应的IP地址
4、浏览器向服务器发起TCP连接,进行TCP连接的三次握手
5、握手成功后,浏览器向服务器发送HTTP请求,请求数据包
6、服务器收到请求,进行处理后将数据发送给浏览器
7、浏览器收到HTTP响应
8、浏览器解析响应,如果响应可以缓存则存入缓存
9、浏览器发送请求获取嵌入在HTML的资源(HTML、CSS、JS等),对于未知类型,会弹出对话框
10、浏览器发送异步请求
11、页面全部渲染结束显示网页
HTTP请求方法
GET和POST的区别?
GET 和POST 本质上就是TCP 连接,并无差别。但是由于HTTP 的规定和浏览器/服务器的限制,导致他们在应用过程中体现出一些不同。
- get 参数通过 url 传递,post 放在 request body 中。
- get 请求在 url 中传递的参数是有长度限制的,而 post 没有。
- get 请求只能进行 url 编码,而 post 支持多种编码方式。
- get 请求会浏览器主动 cache,而 post 支持多种编码方式。
- get 请求参数会被完整保留在浏览历史记录里,而post 中的参数不会被保留。
- GET 产生一个TCP 数据包;POST 产生两个TCP 数据包。
- 对于GET 方式的请求,浏览器会把http header 和data 一并发送出去,服务器响应200(返回数据)
- 对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)
HTTP状态码
HTTP的无连接是什么意思?
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
HTTP的无状态是什么意思?
无状态是指协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后,服务器根据请求,会给我们发送数据过来,但是,发送完,不会记录任何信息。
HTTP1.0、HTTP1.1、HTTP2.0的区别?
HTTP1.0
- HTTP1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接。就像打电话一样,一次只能说一件事,说完就要挂断,又因为TCP连接建立一次需要三次握手,所以效率很低。
如果不想断开连接,需要在HTTP相应的Connection字段指定为keep-live
connection:keep-alive;
HTTP1.1
HTTP1.1引进了持久连接,TCP连接默认不关闭,可以被多个请求复用。客户端和服务端发现对方一段时间没有活动后,可以主动关闭连接;或者客户端在最后一个请求时,主动告诉服务端要关闭连接。响应的顺序必须和请求的顺序一致
HTTP1.0就像打一次电话只能说一次事,HTTP1.1是打完电话先不直接挂断,而是持续一会,这期间如果有事情还可以再次沟通。
HTTP1.1还引入了管道机制,即在同一个TCP连接里,客户端可以同时发送多个请求,这样就进一步改进了HTTP协议的效率。
HTTP2.0
HTTP2.0采用了多路复用,即在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按顺序一一对应。能这样做有一个前提,就是HTTP2.0进行了二进制分帧,即会将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码。
负责这个拆分、组装请求和二进制帧的一层就叫做二进制分帧层
也就是说,老板可以同时下达多个命令,员工也可以收到请求A和请求B,于是先回应A,结果发现处理A非常耗时,于是就发送A请求已经处理好的部分,接着回应B请求,完成后 ,再发送A请求剩下的部分。A请求的两部分响应再组合到一起发送给老板
除此之外还有一些其他的优化,比如Header压缩、服务端推送等
- Header压缩就是压缩老板和员工之间的对话
- 服务端推送就是员工事先把一些老板可能询问的事情提前发送到老板的手机上(缓存)。这样老板想要知道的时候就可以直接读取短信(缓存)了。
HTTP 和 HTTPS 的区别?
HTTPS (Hyper Text Transfer Protocol over SecureSocket Layer):是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP+SSL,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。
HTTPS 采用混合的加密机制,使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性,之后使用对称密钥加密进行通信来保证通信过程的效率。
- 开销:HTTPS协议需要到CA申请证书,一般免费证书较少,因而需要一定费用。
- 端口不同:HTTP和HTTPS使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
- 安全性:HTTP的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比HTTP协议安全。
- 资源消耗:HTTP是超文本传输协议,信息是明文传输;HTTPS则是具有安全性的SSL加密传输协议,需要消耗更多的CPU和内存资源
- 在OSI模型中,HTTP工作于应用层,而HTTPS工作于传输层;
HTTPS 优点
- HTTPS 传输数据过程中使用密钥进行加密,所以安全性更高
- HTTPS 协议可以认证用户和服务器,确保数据发送到正确的用户和服务器
HTTPS 缺点
HTTPS 握手阶段延时较高:由于在进行HTTP 会话之前还需要进行SSL 握手,因此HTTPS 协议握手阶段延时增加
HTTPS 部署成本高:一方面HTTPS 协议需要使用证书来验证自身的安全性,所以需要购买CA证书;另一方面由于采用HTTPS 协议需要进行加解密的计算,占用CPU 资源较多。
ps:对称加密中,双方使用公钥进行解密。虽然数字签名可以保证数据不被替换,但数据是由公钥加密的,如果公钥也被替换,则仍然可以伪造数据,因为用户不知道对方提供的公钥是真是假。为了保证发送方的公钥是真的,CA证书机构会负责颁发一个证书,里面的公钥确保是真的,用户请求服务器时,服务器将证书给用户,这个证书是经由系统内置证书的备案过的。
对称加密
加密与解密使用同样的密钥。对称加密效率较高,被广泛应用于各种加密协议,然而在通讯前需要将密钥发送给对方,容易导致密钥泄漏。
非对称加密
非对称加密使用了一对密钥:公钥和私钥。私钥只能由一方保管,不能外泄,而公钥则可以发给任何请求者。通过公钥加密的数据只能由私钥解开。相比对称加密而言,非对称加密是十分安全的,但是加密和解密效率却没有对称加密高。
HTTPS的通信建立过程?
- 在使用HTTPS是需要保证服务端配置正确了对应的安全证书
- 客户端发送请求到服务端
- 服务端返回公钥和数字证书到客户端
- 客户端接收后会验证证书的安全性,如果通过,则会随机生成一个随机秘钥,用公钥对其加密,发送到服务端
- 服务端接受到这个加密后的随机秘钥后,会用私钥对其解密,随后用这个随机秘钥当做对称加密密钥对需要发送的数据进行对称加密
- 客户端在接收到加密后的数据对称加密密钥与服务器通信。
- SSL加密建立
什么是数字签名?
为了避免数据在传输过程中被替换,比如黑客修改了报文内容,但是用户并不知道,所以需要让发送端做一个数字签名,把数据的摘要信息进行一个加密,比如MD5,得到一个签名,和数据一起发送。然后接收端把数据摘要进行MD5加密,如果和签名一样,则说明数据是正确的
什么是数字证书?
对称加密中,双方使用公钥进行解密。虽然数字签名可以保证数据不被替换,但数据是由公钥加密的,如果公钥也被替换,则仍然可以伪造数据,因为用户不知道对方提供的公钥是真是假。为了保证发送方的公钥是真的,CA证书机构会负责颁发一个证书,里面的公钥确保是真的,用户请求服务器时,服务器将证书给用户,这个证书是经由系统内置证书的备案过的。
其他
Session和Cookie的区别?
Cookie的工作原理 (1)浏览器端第一次发送请求到服务器端 (2)服务器端创建Cookie,该Cookie中包含用户的信息,然后将该Cookie发送到浏览器端 (3)浏览器端再次访问服务器端时会携带服务器端创建的Cookie (4)服务器端通过Cookie中携带的数据区分不同的用户
Cookie用途
- 会话状态管理(如用户登录状态、购物车、游戏分数或其它需要记录的信息)
- 个性化设置(如用户自定义设置、主题等)
- 浏览器行为跟踪(如跟踪分析用户行为等)
Session的工作原理
- 浏览器端第一次发送请求到服务器端,服务器端创建一个Session,同时会创建JSESSIONID(JSESSIONID实际上是一个cookie,服务器用来记录用户session),然后将该Cookie发送至浏览器端
- 浏览器端发送第N(N>1)次请求到服务器端,浏览器端访问服务器端时就会携带该name为JSESSIONID的Cookie对象
- 服务器端根据name为JSESSIONID的Cookie的value(sessionId),去查询Session对象,从而区分不同用户。
区别:
- 数据存放位置不同:cookie数据存放在客户的浏览器上,session数据放在服务器上。
- 安全程度不同:cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。
- 性能使用程度不同:session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用cookie。
- 数据存储大小不同:单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie,而session则存储与服务端,浏览器对其没有限制。
- 会话机制不同:session会话机制是一种服务器端机制,它使用类似于哈希表(可能还有哈希表)的结构来保存信息。cookie是服务器存储在本地计算机上的小块文本,并随每个请求发送到同一服务器。 Web服务器使用HTTP标头将cookie发送到客户端。在客户端终端,浏览器解析cookie并将其保存为本地文件,该文件自动将来自同一服务器的任何请求绑定到这些cookie。
什么是SQL 注⼊? 举个例子
SQL注⼊就是通过把SQL命令插入到Web表单提交或输入域名或⻚面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。
SQL注⼊攻击的总体思路
- 寻找到SQL注⼊的位置
- 判断服务器类型和后台数据库类型
- 针对不同的服务器和数据库特点进行SQL注入攻击
例子:
user: ‘or1=1--
pwd:
String sql = “select * from user_table where username=’ “+userName+” ’ and password=’“+password+” ‘”;
SELECT * FROM user_table WHERE username=’’or 1 = 1 –- and password=’’
应对方法
- 参数绑定
- 使⽤用正则表达式过滤传⼊入的参数
MTU和MSS分别是什么?
MTU:maximum transmission unit,最大传输单元,IP分片的大小,由硬件规定,如以太网的MTU为1500字节。
IP分片解决不同物理网络最大传输单元(MTU) 的不同造成的传输问题。
MSS:maximum segment size,最大分节大小,为TCP数据包每次传输的最大数据分段大小,一般由发送端向对端TCP通知对端在每个分节中能发送的最大TCP数据。MSS值为MTU值减去IPv4 Header(20 Byte)和TCP header(20 Byte)得到。
DDOS 攻击?
客户端向服务端发送请求链接数据包,服务端向客户端发送确认数据包,客户端不向服务端发送确认数据包,服务器一直等待来自客户端的确认 没有彻底根治的办法,除非不使用TCP DDos 预防:
1)限制同时打开SYN半链接的数目 2)缩短SYN半链接的Time out 时间 3)关闭不必要的服务