“知其然,知其所以然。最近看了《图解HTTP》、《图解TCPIP》、《小林coding》 和谢希仁的《计算机网络》顺带做了一点笔记。
OSI七层:物理层、数据链路层、网络层、传输层、会话层、表示层、应用层
TCP/IP五层:物理层、数据链路层、网络层、传输层、应用层
七层网络体系结构各层的主要功能:
DNS
, 支持万维网应用的HTTP
协议,支持电子邮件的SMTP
协议等。TCP
:提供面向连接的、可靠的数据传输服务;UDP
:提供无连接的、尽最大努力的数据传输服务,但不保证数据传输的可靠性。IP
协议。IP
数据包组装成帧,并再相邻节点的链路上传送帧。应用层:HTTP
、DNS
、FTP
、SMTP
传输层:TCP
、UDP
网络层:IP
、ICMP
、路由器、防火墙
数据链路层:网卡、网桥、交换机
物理层:中继器、集线器
三次握手过程:
SYN
标志的数据包——服务端 一次握手 客户端进入syn_sent
状态SYN/ACK
标志的数据包——客户端 二次握手 服务端进入syn_rcvd
ACK
标志的数据包——服务端 三次握手 连接就进入Established
状态为什么三次: 主要是为了建立可靠的通信信道,保证客户端与服务端同时具备发送、接收数据的能力。
为什么两次不行?
TCP
协议的通信双方, 都必须维护一个序列号, 以标识发送出去的数据包中, 哪些是已经被对方收到的。三次握手的过程即是通信双方 相互告知序列号起始值, 并确认对方已经收到了序列号起始值的必经步骤;如果只是两次握手, 至多只有连接发起方的起始序列号能被确认, 另一方选择的序列号则得不到确认)。FIN
标志的数据包——服务端,关闭与服务端的连接 ,客户端进入FIN-WAIT-1
状态FIN
,它发回⼀ 个 ACK
,确认序号为收到的序号加1
,服务端就进入了CLOSE-WAIT
状态FIN
数据包——客户端,关闭与客户端的连接,客户端就进入FIN-WAIT-2
状态FIN
,发回 ACK
报⽂确认,并将确认序号设置为收到序号加1
,客户端进入TIME-WAIT
状态为什么四次:因为需要确保客户端与服务端的数据能够完成传输。
CLOSE-WAIT: 这种状态的含义其实是表示在等待关闭。
TIME-WAIT: 为了解决网络的丢包和网络不稳定所带来的其他问题,确保连接方能在时间范围内,关闭自己的连接。
服务器在收到客户端的FIN
报文段后,可能还有一些数据要传输,所以不能马上关闭连接,但是会做出应答,返回ACK
报文段。
接下来可能会继续发送数据,在数据发送完后,服务器会向客户端发送FIN
报文,表示数据已经发送完毕,请求关闭连接。服务器的ACK
和FIN
一般都会分开发送,从而导致多了一次,因此一共需要四次挥手。
netstat -an | grep TIME_WAIT | wc -l //查看连接数等待time_wait状态连接数
可能原因:高并发短连接的TCP
服务器上,当服务器处理完请求后立刻按照主动正常关闭连接
解决:负载均衡服务器;Web服务器首先关闭来自负载均衡服务器的连接
在三次握手的过程中,服务器为了响应一个受到的SYN
报文段,会分配并初始化连接变量和缓存,然后服务器发送一个SYN/ACK
报文段进行响应,并等待客户端的ACK
报文段。如果客户不发送ACK
来完成该三次握手的第三步,最终(通常在一分多钟之后)服务器将终止该半开连接并回收资源。这种TCP
连接管理协议的特性就会有这样一个漏洞,攻击者发送大量的TCP SYN
报文段,而不完成第三次握手的步骤。随着这种SYN
报文段的不断到来,服务器不断为这些半开连接分配资源,从而导致服务器连接资源被消耗殆尽。这种攻击就是SYN
泛供攻击。
为了应对这种攻击,现在有一种有效的防御系统,称为SYN cookie。SYN cookie的工作方式如下:
SYN
报文段时,它并不知道该报文段是来自一个合法的用户,还是这种SYN洪泛攻击的一部分。因为服务器不会为该报文段生成一个半开的连接。相反,服务器生成一个初始TCP
序列号,该序列号是SYN报文段的源IP地址和目的IP地址,源端口号和目的端口号以及仅有服务器知道的秘密数的复杂函数(散列函数)。这种精心制作的初始序列号称为为“cookie”。服务器则发送具有这种特殊初始序号的SYN/ACK
报文分组。服务器并不记忆该cookie或任何对应于SYN的其他状态信息。ACK
报文段。当服务器收到该ACK
报文段,需要验证该ACK是与前面发送的某个SYN
相对应。由于服务器并不维护有关SYN
报文段的记忆,所以服务器通过使用SYN/ACK
报文段中的源和目的IP地址与端口号以及秘密数运行相同的散列函数。如果这个函数的结果(cookie值)加1和在客户的ACK报文段中的确认值相同的话,那么服务器就会认为该ACK
对应于较早的SYN
报文段,因此它是合法的。服务器则会生成一个套接字的全开连接。ACK
报文段,说明之前的SYN
报文段是洪泛攻击的一部分,但是它并没有对服务器产生危害,因为服务器没有为它分配任何资源。主要有两个原因:
ACK
报文段可能丢失,因而使处在LAST-ACK
状态的服务器收不到确认。服务器会超时重传FIN+ACK
报文段,客户端就能在2MSL时间内收到这个重传的FIN+ACK
报文段,接着客户端重传一次确认,重启计时器。最好,客户端和服务器都正常进入到CLOSED
状态。如果客户端在TIME-WAIT
状态不等待一段时间,而是再发送完ACK
报文后立即释放连接,那么就无法收到服务器重传的FIN+ACK
报文段,因而也不会再发送一次确认报文。这样,服务器就无法按照正常步骤进入CLOSED
状态。ACK
确认报文段后,再经过时间2MSL
,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。当移动设备的网络从4G
切换到WiFi
时,意味着IP地址变化了,那么必须要断开连接,然后重新连接,而建立连接的过程包含TCP三次握手和TLS四次挥手的时延,以及TCP慢启动的减速过程,给用户的感觉就是突然网络卡顿了一下,所以说,迁移的成本是很高的。
http3是怎么解决连接迁移
HTTP3
中QUIC
协议没有用四元组的方式来"绑定”连接,而是通过连接ID来标记通信的两个端点,客户端和服务器可以各自选择一组ID来标记自己,因此即使移动设备的网络变化后,导致IP地址变化了,只要仍保有上下文信息(比如连接ID、TLS 密钥等),就可以"无缝"地复用原连接,消除重连的成本,没有丝毫卡顿感,达到了连接迁移的功能。
类型 | 特点 | 性能 | 应用过场景 | 首部字节 |
---|---|---|---|---|
TCP | 面向连接、可靠、字节流 | 传输效率慢、所需资源多 | 文件、邮件传输 | 20-60 |
UDP | 无连接、不可靠、数据报文段 | 传输效率快、所需资源少 | 语音、视频、直播 | 8个字节 |
基于TCP的协议:HTTP
、FTP
、SMTP
基于UDP的协议: RIP
、DNS
、SNMP
TCP通过:应用数据分割、对数据包进行编号、校验和、流量控制、拥塞控制、超时重传等措施保证数据的可靠传输。
拥塞控制目的:为了防止过多的数据注入到网络中,避免网络中的路由器、链路过载。
拥塞控制过程:TCP维护一个拥塞窗口,该窗口随着网络拥塞程度动态变化,通过慢开始、拥塞避免等算法减少网络拥塞的发生。
TCP粘包是指:发送方发送的若干包数据到接收方接收时粘成一包
发送方原因:
TCP默认使用Nagle算法(主要作用:减少网络中报文段的数量):
收集多个小分组,在一个确认到来时一起发送、导致发送方可能会出现粘包问题
接收方原因:
TCP将接收到的数据包保存在接收缓存里,如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度,多个包就会被缓存,应用程序就有可能读取到多个首尾相接粘到一起的包。
UDP
是基于报文发送的,在UDP
首部采用了16bit来指示UDP
数据报文的长度,因此在应用层能很好的将不同的数据报文区分开,从而避免粘包和拆包的问题。TCP
是基于字节流的,虽然应用层和传输层之间的数据交互是大小不等的数据块,但是TCP
把这些数据块仅仅看成一连串无结构的字节流,没有边界;TCP
的首部没有表示数据长度的字段,基于上面两点,在使用TCP
传输数据时,才有粘包或者拆包现象发生的可能。解决粘包问题:解决问题的关键在于如何给每个数据包添加边界信息
最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪,通过使用某种方案给出边界,例如:
FTP
协议正是这么做的。但问题在于如果数据正文中也含有\r\n,则会误判为消息的边界。TCP报文格式:
源端口号和目的端口号:
用于寻找发端和收端应用进程。这两个值加上IP
首部源端IP地址和目的端IP
地址唯一确定一个TCP
连接。
序号字段:
序号用来标识从TCP
发端向TCP
收端发送的数据字节流,它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动,则 TCP
用序号对每个字节进行计数。序号是32 bit的无符号数,序号到达 2^32-1后又从0开始。
当建立一个新的连接时,SYN
标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN(Initial Sequence Number)。该主机要发送数据的第一个字节序号为这个ISN加1,因为SYN
标志消耗了一个序号
确认序号:
既然每个传输的字节都被计数,确认序号包含发送确认的一端所期望收到的下一个序号。因此,确认序号应当是上次已成功收到数据字节序号加 1。只有ACK
标志为 1时确认序号字段才有效。发送ACK
无需任何代价,因为 32 bit的确认序号字段和A C K标志一样,总是TCP首部的一部分。因此,我们看到一旦一个连接建立起来,这个字段总是被设置, ACK标志也总是被设置为1。TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此,连接的每一端必须保持每个方向上的传输数据序号。
首都长度:
首部长度给出首部中 32 bit字的数目。需要这个值是因为任选字段的长度是可变的。这个字段占4 bit,因此TCP最多有6 0字节的首部。然而,没有任选字段,正常的长度是 20字节。
标志字段:在TCP
首部中有 6个标志比特,它们中的多个可同时被设置为1。
URG
紧急指针(u rgent pointer)有效ACK
确认序号有效。PSH
接收方应该尽快将这个报文段交给应用层。RST
重建连接。SYN
同步序号用来发起一个连接。这个标志和下一个标志将在第 1 8章介绍。FIN
发端完成发送任务。窗口大小:
TCP
的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数,起始于确认序号字段指明的值,这个值是接收端期望接收的字节。窗口大小是一个 16 bit字段,因而窗口大小最大为 65535字节。
检验和:
检验和覆盖了整个的 TCP
报文段:TCP
首部和TCP
数据。这是一个强制性的字段,一定是由发端计算和存储,并由收端进行验证。
紧急指针:
只有当URG
标志置1时紧急指针才有效。紧急指针是一个正的偏移量,和序号字段中的值相加表示紧急数据最后一个字节的序号。TCP
的紧急方式是发送端向另一端发送紧急数据的一种方式。
选项:
最常见的可选字段是最长报文大小,又称为 MSS
(Maximum Segment Size)。每个连接方通常都在通信的第一个报文段(为建立连接而设置 SYN
标志的那个段)中指明这个选项。它指明本端所能接收的最大长度的报文段。
UDP报文格式:
端口号:
用来表示发送和接受进程。由于 IP
层已经把I P数据报分配给TCP
或 UDP
(根据I P首部中协议字段值),因此TCP
端口号由TCP
来查看,而 UDP
端口号由 UDP
来查看。TCP
端口号与 UDP
端口号是相互独立的。
长度:
UDP
长度字段指的是 UDP
首部和 UDP
数据的字节长度。该字段的最小值为 8字节(发送一份0字节的 UDP
数据报是 O K)。
检验和:
UDP
检验和是一个端到端的检验和。它由发送端计算,然后由接收端验证。其目的是为了发现 UDP
首部和数据在发送端到接收端之间发生的任何改动。
IP报文格式:普通的IP首部长为20个字节,除非含有可选项字段。
4位版本:目前协议版本号是4,因此IP有时也称作IPV4.
4位首部长度:
首部长度指的是首部占32bit
字的数目,包括任何选项。由于它是一个4比特字段,因此首部长度最长为60个字节。
服务类型(TOS):
服务类型字段包括一个3bit
的优先权字段(现在已经被忽略),4bit
的TOS子字段和1bit未用位必须置0。4bit
的TOS分别代表:最小时延,最大吞吐量,最高可靠性和最小费用。4bit中只能置其中1比特。如果所有4bit均为0,那么就意味着是一般服务。
总长度:
总长度字段是指整个IP数据报的长度,以字节为单位。利用首部长度和总长度字段,就可以知道IP数据报中数据内容的起始位置和长度。由于该字段长16bit
,所以IP数据报最长可达65535字节。当数据报被分片时,该字段的值也随着变化。
标识字段:
标识字段唯一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1。
生存时间:
TTL(time-to-live)生存时间字段设置了数据报可以经过的最多路由器数。它指定了数据报的生存时间。TTL的初始值由源主机设置(通常为 3 2或6 4),一旦经过一个处理它的路由器,它的值就减去 1。当该字段的值为 0时,数据报就被丢弃,并发送 ICMP
报文通知源主机。
首部检验和:
首部检验和字段是根据 I P首部计算的检验和码。它不对首部后面的数据进行计算。ICMP
、IGMP
、UDP
和TCP
在它们各自的首部中均含有同时覆盖首部和数据检验和码。
以太网报文格式:
目的地址和源地址: 是指网卡的硬件地址(也叫MAC 地址),长度是48 位,是在网卡出厂时固化的。
数据:
以太网帧中的数据长度规定最小46 字节,最大1500 字节,ARP
和RARP
数据包的长度不够46 字节,要在后面补填充位。最大值1500 称为以太网的最大传输单元(MTU
),不同的网络类型有不同的MTU
,如果一个数据包从以太网路由到拨号链路上,数据包度大于拨号链路的MTU
了,则需要对数据包进行分片fragmentation)。ifconfig
命令的输出中也有“MTU:1500”。注意,MTU
个概念指数据帧中有效载荷的最大长度,不包括帧首部的长度。
TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和流量控制等方法实现了可靠性传输。
TCP
段,重新发送。TCP
传输的过程中,每次接收方收到数据后,都会对传输方进行确认应答。也就是发送ACK
报文,这个ACK
报文当中带有对应的确认序列号,告诉发送方,接收到了哪些数据,下一次的数据从哪里发。TCP
可靠性的同时,提高性能。TCP
协议报头中的窗口大小有关。在进行数据传输时,如果传输的数据比较大,就需要拆分为多个数据包进行发送。TCP
协议需要对数据进行确认后,才可以发送下一个数据包。这样一来,就会在等待确认应答包环节浪费时间。为了避免这种情况,TCP
引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。
从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组,滑动窗口右边是还没有轮到的分组。
滑动窗口里面也分为两块,一块是已经发送但是未被确认的分组,另一块是窗口内等待发送的分组。随着已发送的分组不断被确认,窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动,让还没轮到的分组进入窗口内。
可以看到滑动窗口起到了一个限流的作用,也就是说当前滑动窗口的大小决定了当前TCP
发送包的速率,而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。
A在给B传输数据, A却没有收到B反馈的TCP
,A就认为B发送的数据包丢失了..进而会重新传输这个丢失的数据包。然而实际情况有可能此时有太多主机正在使用信道资源,导致网络拥塞了。重传数据浪费了资源,所以要进行拥塞控制。发送发不知道一次发多少数据合适,所以设置一个拥塞窗口。
TCP拥塞控制原理是通过:慢启动、拥塞避免、快重传、快启动
发送方维持一个叫做拥塞窗口cwnd (congestion window)的状态变量。当cwndssthresh时, 改用拥塞避免算法。
Reno
、Cubic
等。Vegas
、FastTCP
等。BBR
。Remy
。HTTP1.0:服务器处理完成后立即断开TCP
连接(无连接),服务器不跟踪每个客户端也不记录过去的请求(无状态)
HTTP1.1: KeepAlived
长连接避免了连接建立和释放的开销;通过Content-Length
来判断当前请求数据是否已经全部接受(有状态)
HTTP2.0:引入二进制数据帧和流的概念,其中帧对数据进行顺序标识;因为有了序列,服务器可以并行的传输数据。
无状态的好坏
HTTP
的状态,所以不需要额外的资源来记录状态信息,这能减 轻服务器的负担,能够把更多的 CPU
和内存用来对外提供服务。解决无状态的问题,解法方案有很多种,其中比较简单的方式用 Cookie
和Session
技术。
Entity tag
,If-Match
)Host
头域,不在以IP
为请求方标志request
可以使用同一个连接传输(最后根据每个request
上的id号组合成正常的请求)header
带有大量的信息,并且得重复传输,2.0使用encoder
来减少需要传输的hearder
大小google
的SPDUY
(1.0的一种升级)一样HTTP
明文传输,不对数据进行加密安全性较差。HTTPS
(HTTP + SSL / TLS)的数据传输过程是加密的,安全性较好。HTTPS
协议需要申请 CA
证书,一般免费证书较少,因而需要一定费用。证书颁发机构如:Symantec
、Comodo
、DigiCert
和 GlobalSign
等。HTTP
页面响应速度比 HTTPS
快,这个很好理解,由于加了一层安全层,建立连接的过程更复杂,也要交换更多的数据,难免影响速度。HTTP
协议运行在TCP
(三次握手)之上,所有传输的内容都是明文,HTTPS
运行在SSL/TLS
之上,SSL/TLS
运行在TCP
之上,所有传输的内容都经过加密的。HTTPS
和 HTTP
使用的是完全不同的连接方式,用的端口也不一样,前者是 443
,后者是 80
。HTTP | HTTPS |
---|---|
默认端口80 | 默认端口443 |
明文传输、数据未加密、安全性较差 | 传输协议ssl加密、安全性较好 |
响应速度快,消耗资源少 | 响应速度慢、消耗资源多,需要用到CA证书 |
HTTPS
相比 HTTP
无论是响应时间还是耗电量都有大幅度上升。HTTPS
的安全是有范围的,在黑客攻击、服务器劫持等情况下几乎起不到作用。HTTPS
需要更多的服务器资源,也会导致成本的升高。SSL
证书给客户端,内容包括:证书的发布机构、有效期、所有者、签名以及公钥加密流程按图中的序号分为:
HTTPS
网址,然后连接到server
的443端口(HTTPS
默认端口,类似于HTTP
的80端口)。HTTPS
协议的服务器必须要有一套数字CA
(Certification Authority)证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存,不可泄漏。公钥则是附带在证书的信息中,可以公开的。证书本身也附带-一个证书电子签名,这个签名用来验证证书的完整性和真实性,可以防止证书被篡改。KEY
,并使用公钥A将其加密。KEY
发送给服务器,作为后面对称加密的密钥。KEY
之后会使用私钥B将其解密。经过以上这些步骤,客户端和服务器终于建立了安全连接,完美解决了对称加密的密钥泄露问题,接下来就可以用对称加密愉快地进行通信了。KEY
)对数据进行对称加密并发送给客户端,客户端使用相同的密钥(随机码KEY
)解密数据。100
:Continue 一一 继续。客户端应继续其请求。
200
:OK 一一 请求成功。一 般用于GET与POST请求。
301
:Moved Permanently 一一 永久重定向。
302
:Found 一一 暂时重定向。
400
:Bad Request 一一 客户端请求的语法错误,服务器无法理解。请求没有包含host头
403
:Forbideen 一一 服务器理解请求客户端的请求,但是拒绝执行此请求。禁止客户访问该资源
404
:Not Found 一一 服务器无法根据客户端的请求找到资源(网页)。资源未找到
500
:Internal Server Error 一一 服务器内部错误,无法完成请求。
502
:Bad Gateway 一一 作为网关或者代理服务器尝试执行请求时,从远程服务器接收到了无效的响应。
301
为永久重定向,302
为临时重定向
共同点: 301
和302
状态码都表示重定向,就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址,这个地址可以从响应的Location首部中获取(用户看到的效果就是他输入的地址A瞬间变成了另一个地址B)。
不同点: 301
表示旧地址A的资源已经被永久地移除了(这个资源不可访问了),搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址;302
表示旧地址A的资源还在(仍然可以访问),这个重定向只是临时地从旧地址A跳转到地址B,搜索引擎会抓取新的内容而保存旧的网址。SEO中302
好于301
。
补充,重定向原因:
对称加密算法:
双方持有相同的密钥,且加密速度快,典型对称加密算法:DES
、AES
非对称加密算法:
密钥成对出现(私钥、公钥),私钥只有自己知道,不在网络中传输;而公钥可以公开。相比对称加密速度较慢,典型的非对称加密算法有:AES
、DSA
方法 | 描述 |
---|---|
GET | 像特定资源发送请求,查询数据,并返回实体 |
POST | 向指定资源提交数据进行处理,可能会导致新的资源建立、已有的资源修改 |
PUT | 向服务器上传新的内容 |
HEAD | 类似GET请求,返回的响应式中没有具体内容,用于获取报头 |
DELETE | 请求服务器删除指定标识的资源 |
OPTIONS | 可以原来向服务器发送请求来测试服务器的功能性 |
TRACE | 回显服务器收到的请求,用于测试和诊断 |
CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器 |
GET | POST | |
---|---|---|
HTTP规范 | GET用于信息获取 | 修改服务器上的资源的请求 |
可见性 | 数据在URL中对所有人可见 | 数据不会显示在URL中 |
安全性 | 与post相比,get的安全性较差,因为所发送的数据是URL的一部分 | 安全,因为参数不会被保存在浏览器历史或web服务器日志中 |
数据长度 | 受限制,最长2kb | 无限制 |
编码类型 | application/x-www-form-urlencoded | multipart/form-data |
缓存 | 能被缓存 | 不能被缓存 |
先说明下安全和幂等的概念:
DSA
协议里,所谓的「安全」是指请求方法不会「破坏」服务器上的资源。那么很明显 GET 方法就是安全且幂等的,因为它是「只读」操作,无论操作多少次,服务器上的数据 都是安全的,且每次的结果都是相同的。
POST
因为是「新增或提交数据」的操作,会修改服务器上的资源,所以是不安全的,且多次提交数据 就会创建多个资源,所以不是幂等的。
转发是服务器行为,重定向是客户端行为
重定向:redirect:
地址栏发生变化
重定向可以访问其他站点(服务器)的资源
重定向是两次请求。不能使用request对象来共享数据
转发:forward:
转发地址栏路径不变
转发只能访问当前服务器下的资源
转发是一次请求,可以使用request
对象共享数据
Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式,但两者有所区别:
Cookie
数据保存在客户端(浏览器端),Session
数据保存在服务器端。
cookie
不是很安全,别人可以分析存放在本地的Cookie
并进行欺骗,考虑到安全应当使用session。
Cookie
⼀般⽤来保存⽤户信息,Session
的主要作⽤就是通过服务端记录⽤户的状态
过程:DNS
解析、TCP
连接、发送HTTP
请求、服务器处理请求并返回HTTP
报文、浏览器渲染、结束
DNS
缓存(维护一张域名与IP的对应表);DNS
缓存(维护一张域名与IP的对应表) ;DNS
服务器(递归查询),本地域名服务器查询自己的DNS
缓存,如果没有,则进行迭代查询。将本地dns服务器将IP返回给操作系统,同时缓存IP。TCP
的三次握手,建立TCP
连接。浏览器会以一个随机端口(1024-65535) 向服务端的web程序80端口发起TCP
的连接。TCP
连接后发起HTTP请求。HTTP
请求,客户端得到html
代码。服务器web应用程序收到HTTP
请求后,就开始处理请求,处理之后就返回给浏览器html
文件。html
代码,并请求html
中的资源。如何查看 TCP 的连接状态?TCP 的连接状态查看,在 Linux 可以通过 netstat -napt 命令查看。
DNS
占用53号端口,同时使用TCP
和UDP
协议。那么DNS
在什么情况下使用这两种协议?
DNS在区域传输的时候使用TCP协议,其他时候使用UDP协议。DNS
服务器查询域名,一般返回的内容都不超过512字节,用UDP
传输即可。不用经过TCP
三次握手,这样DNS
服务器负载更低,响应更快。虽然从理论上说,客户端也可以指定向DNS
服务器查询的时候使用TCP
,但事实上,很多DNS
服务器进行配置的时候,仅支持UDP
查询包。TCP
而不是UDP
,因为数据同步传送的数据量比一个请求应答的数据量要多得多。TCP
是一种可靠连接,保证了数据的准确性。简单地说,ARP
是借助 ARP
请求与 ARP
响应两种类型的包确定 MAC
地址的。
ARP
请求,这个包中包含了想要知道的 MAC
地址的主机 IP 地址。ARP
请求时,会去拆开 ARP
请求包里的内容,如果 ARP
请求包中 的目标 IP 地址与自己的 IP 地址一致,那么这个设备就将自己的 MAC 地址塞入 ARP
响应包返回 给主机。操作系统通常会把第一次通过 ARP
获取的 MAC
地址缓存起来,以便下次直接从缓存中找到对应 IP 地 址的 MAC
地址。不过, MAC
地址的缓存是有一定期限的,超过这个期限,缓存的内容将被清除
ARP 协议是已知 IP 地址求 MAC
地址,那 RARP
协议正好相反,它是已知 MAC
地址求 IP 地址。例如 将打印机服务器等小型嵌入式设备接入到网络时就经常会用得到。
通常这需要架设一台 RARP
服务器,在这个服务器上注册设备的 MAC
地址及其 IP 地址。然后再将 这个设备接入到网络,接着:
MAC
地址是XXXX,请告诉我,我的IP地址应该是什么」的请求信息。RARP
服务器接到这个消息后返回「 MAC
地址为 XXXX 的设备,IP地址为 XXXX」的信息给这个 设备。最后,设备就根据从 RARP
服务器所收到的应答信息设置自己的 IP 地址
DDos
全称Distributed Denial of Service,分布式拒绝服务攻击。最基本的DOS攻击过程如下:
DDos
则是采用分布式的方法,通过在网络上占领多台“肉鸡”,用多台计算机发起攻击。
DDos
攻击现在基本没啥作用了,因为服务器的性能都很好,而且是多台服务器共同作用,1V1的模式黑客无法占上风。对于DDos
攻击,预防方法有:
XSS也称cross-sitescripting,跨站脚本。这种攻击是由于服务器将攻击者存储的数据原原本本地显示给其他用户所致的。比如一个存在XSS漏洞的论坛,用户发帖时就可以引入带有< script>标签的代码,导致恶意代码的执行。
预防措施有:
SQL
注入就是在用户输入的字符串中加入SQL
语句,如果在设计不良的程序中忽略了检查,那么这些注入进去的SQL
语句就会被数据库服务器误认为是正常的SQL
语句而运行,攻击者就可以执行计划外的命令或访问未被授权的数据。
SQL
注入的原理主要有以下4点:
避免SQL
注入的一些方法:
SQL
。 在知道了SQL
注入的原理之后,我们同样也了解到MySQL
有预编译的功能,指的是在服务器启动时,MySQL
Client把SQL
语句的模板(变量采用占位符进行占位)发送给MySQL
服务器,MySQL
服务器对SQL
语句的模板进行编译,编译之后根据语句的优化分析对相应的索引进行优化,在最终绑定参数时把相应的参数传送给MySQL
服务器,直接进行执行,节省了SQL
查询时间,以及MySQL
服务器的资源,达到一次编译、多次执行的目的,除此之外,还可以防止SQL注入。
具体是怎样防止SQL
注入的呢?实际上当将绑定的参数传到MySQL
服务器,MySQL
服务器对参数进行编译,即填充到相应的占位符的过程中,做了转义操作。我们常用的JDBC就有预编译功能,不仅提升性能,而且防止SQL
注入。
socket
,用函数socket()
socket
上,用函数bind()
listen()
accept()
send()
和recv()
,或者read()
和write()
socket
,用函数socket()
connect()
send()
和recv()
,或read()
和write()
nginx负载均衡的三种方式主要是轮询模式、weight权重模式、ip_hash。
当一台服务器的单位时间内的访问量越大时,服务器压力就越大,大到超过自身承受能力时,服务器就会崩溃。为了避免服务器崩溃,让用户有更好的体验,我们通过负载均衡的方式来分担服务器压力。
涉及到的linux命令
参考链接:
END