暴雪战网官方网站入口,用jsp实现网站开发的流程,能源公司网站建设,湖州市城乡建设局网站文章目录 力推的计网神课get请求和post请求的区别在浏览器网址输入一个url后直到浏览器显示页面的过程常用状态码session 和 cookie的区别TCP的三次握手和四次挥手七层OSI模型#xff08;TCP/IP协议模型#xff09;各种io模型的知识http协议和tcp协议的区别https和http的区别… 文章目录 力推的计网神课get请求和post请求的区别在浏览器网址输入一个url后直到浏览器显示页面的过程常用状态码session 和 cookie的区别TCP的三次握手和四次挥手七层OSI模型TCP/IP协议模型各种io模型的知识http协议和tcp协议的区别https和http的区别lvsnginxHAProxyTCP和UDP的区别TCP如何实现可靠传输一次RPC调用的整个调用链路http restful 和 RPC的区别各自适用的场景DNS协议用到了什么传输层协议服务端出现大量TIME_WAIT是什么原因导致的 力推的计网神课
标题链接中科大郑烇、杨坚全套《计算机网络自顶向下方法 第7版》课程视频链接
get请求和post请求的区别
常规回答
GET在浏览器回退时是无害的而POST会再次提交请求。GET产生的URL地址可以被Bookmark而POST不可以。GET请求会被浏览器主动cache而POST不会除非手动设置。GET请求只能进行url编码而POST支持多种编码方式。GET请求参数会被完整保留在浏览器历史记录里而POST中的参数不会被保留。GET请求在URL中传送的参数是有长度限制的而POST没有。对参数的数据类型GET只接受ASCII字符而POST没有限制。GET比POST更不安全因为参数直接暴露在URL上所以不能用来传递敏感信息。GET参数通过URL传递POST放在Request body中
深度回答 两者实质没有区别无论 GET 还是 POST用的都是同一个传输层协议TCP所以在传输上没有区别。但是我们对这两种方法传递参数有着不一样的约定即GET参数通过URL传递POST放在Request body中。
// GET方法
GET /index.html?nametechguideage22 HTTP/1.1
Host: localhost// POST方法
POST /index.html HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencodednametechguideage22第一种回答的公式化区分并不绝对随便举两个例子比如我们也可以在POST请求中url中写入参数或者GET请求中的body携带参数这只是我们协议的约定而已只要浏览器和服务器支持技术上可行。再比如从传输的角度来说GET和POST也都是不安全的因为 HTTP 在网络上是明文传输的只要在网络节点上捉包就能完整地获取数据报文。 链接 https://www.oschina.net/news/77354/http-get-post-different https://github.com/febobo/web-interview/issues/145 主要方法对比
序号请求方法描述1GET资源的查操作2POST增资源。如果两个请求相同后一个请求不会把第一个请求覆盖掉而是存在两份相同的资源非幂等性。3PUT改资源。如果两个请求相同后一个请求会把第一个请求覆盖掉此时服务器只存在一份此资源幂等性。4DELETE资源的删操作5HEAD仅返回首部。允许客户端在未获取实际资源的情况下对资源的首部进行检查。可以查看资源是否存在、资源类型等。6TRACE向目的服务器端发起一个“回环”诊断。客户端发送请求到达服务器时服务器会弹回一条TRACE响应并在响应主体中携带服务器收到的原始请求报文的最终模样。这样客户端就可以查看HTTP请求报文在发送的途中是否被中间的防火墙、代理、网关等修改过。7OPTIONS用于获取当前URL所支持的方法。若请求成功则它会在HTTP头中包含一个名为Allow的头值是所支持的方法如GET、POST。 链接https://segmentfault.com/a/1190000013182974 在浏览器网址输入一个url后直到浏览器显示页面的过程
整体流程
URL解析 DNS解析 浏览器发起TCP连接 服务器处理http请求 浏览器接收响应 浏览器渲染页面
URL解析
url自动补全安全检查https、访问限制黑名单缓存检查
输入相同的URL浏览器会根据缓存机制决定是直接使用先前存储的资源还是向源服务器再次发送请求。判断的依据是缓存更新周期 缓存最后修改时间 是否大于 当前时间。 链接https://juejin.cn/post/7042192043216470047 DNS 查询
DNSDomain Name System域名系统负责域名到IP地址的映射解析比如www.baidu.com到167.23.10.2前者有更好的可读性后者是计算机网络协议的IP地址。
1浏览器会首先查看本地硬盘的 hosts 文件看看其中有没有和这个域名对应的规则如果有的话就直接使用 hosts 文件里面的 ip 地址。 2否则浏览器会先向本地 DNS 服务器发起请求由于本地 DNS 服务器没有缓存不能直接将域名转换为 IP 地址需要采用递归或者迭代查询的方式依次向根域名服务器共13个、顶级域名服务器.com、权威域名服务器baidu.com发起查询请求直至找到一个或一组 IP 地址返回给浏览器。 3. 浏览器发起TCP连接
解析完url后浏览器会向目标服务器的固定ip和端口发起TCP连接连接成功后发送一个 HTTP 请求。 TCP报头中的源端口号和目的端口号传输层同IP数据报中的源IP与目的IP网络层唯一确定一条TCP连接所以TCP连接是端对端的面向字节流的连接。同时由于最大报文段MSS的限制应用层的报文下发到传输层通常需要切分成多个报文段分开发送比如数据链路层的最大传输单元MTU是1500个字节传输层和网络层需要添加20个字节的首部那么报文段的实际数据大小最大为1460 bytes。注意这里的序号和确认号都是指每个报文段的第一个字节序号。
服务器处理http请求 浏览器接收响应
1处理http请求
内容包括请求方法URI协议/版本、请求头(Request Header)和请求正文三个部分。 举例
// POST方法
POST /index.html HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencodednametechguideage222接收http响应
HTTP响应也由三个部分组成分别是状态行、消息报头、响应正文。
HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charsetISO-8859-1
Content-Length: 122html
head
titleWrox Homepage/title
/head
body
!-- body goes here --
/body
/html浏览器接收到来自服务器的响应资源后会对资源进行分析。
查看 Response header根据不同状态码做不同的事比如上面提到的重定向。如果响应资源进行了压缩比如 gzip还需要进行解压。对响应资源做缓存。根据MIME 类型content-type解析内容比如 HTML、Image各有不同的解析方式等等…
3连接过程
这里不对三次握手和四次挥手详细展开留在专门的问题讲解本题聚焦在流程串联。 链接 https://zhuanlan.zhihu.com/p/133906695 https://juejin.cn/post/6844903922084085773 浏览器渲染页面 加载根据请求的URL进行域名解析向服务器发起请求接收文件HTML、JS、CSS、图象等。 解析对加载到的资源HTML、JS、CSS等进行语法解析生成相应的内部数据结构比如HTML的DOM树JS的对象属性表CSS的样式规则树等等 渲染构建渲染树对各个元素进行位置计算、样式计算等等然后根据渲染树对页面进行渲染可以理解为“画”元素
注意这几个过程不是完全孤立的会有交叉比如HTML加载后就会进行解析然后拉取HTML中指定的CSS、JS等。不需要深入了解了解核心机制即可。 链接https://www.zhihu.com/question/20117417 常用状态码
1概括 2常用状态码解释
状态码描述301被请求的资源已永久移动到新位置并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。302请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的客户端应当继续向原有地址发送以后的请求。304如果客户端发送了一个带条件的GET请求且该请求已被允许而文档的内容自上次访问以来或者根据请求的条件并没有改变则服务器应当返回这个状态码。4001、语义有误当前请求无法被服务器理解。除非进行修改否则客户端不应该重复提交这个请求。2、请求参数有误。401当前请求需要用户验证。403服务器已经理解请求但是拒绝执行它。与401响应不同的是身份验证并不能提供任何帮助而且这个请求也不应该被重复提交。404请求失败请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。405请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。500服务器遇到了一个未曾预料的状况导致了它无法完成对请求的处理。一般来说这个问题都会在服务器的程序码出错时出现。502作为网关或者代理工作的服务器尝试执行请求时从上游服务器接收到无效的响应。503由于临时的服务器维护或者过载服务器当前无法处理请求。这个状况是临时的并且将在一段时间以后恢复。504作为网关或者代理工作的服务器尝试执行请求时未能及时从上游服务器URI标识出的服务器例如HTTP、FTP、LDAP或者辅助服务器例如DNS收到响应。
3Last-Modified/If-Modified-Since (304 not modified)
浏览器第二次跟服务器请求这个资源时在请求头上加上If-Modified-Since的header这个header的值就是上一次请求时返回的Last-Modified的值。
服务器再次收到资源请求时根据浏览器传过来If-Modified-Since和资源在服务器上的最后修改时间判断资源是否有变化如果没有变化则返回304 Not Modified但是不会返回资源内容如果有变化就正常返回资源内容。当服务器返回304 Not Modified的响应时响应头中不会再添加Last-Modified的header因为既然资源没有变化那么Last-Modified也就不会改变这时服务器返回304时的响应头。 链接https://juejin.cn/post/6844903983874572295 session 和 cookie的区别
由于HTTP协议是无状态的协议所以服务端需要记录用户的状态时就需要用某种机制来识具体的用户这个机制就是Session。Session是在服务端保存的一个数据结构用来跟踪用户的状态这个数据可以保存在集群、数据库、文件中。
Cookie是客户端保存用户信息的一种机制用来记录用户的一些信息也是实现Session的一种方式。第一次创建Session的时候服务端会在HTTP协议中告诉客户端需要在 Cookie 里面记录一个Session ID以后每次请求把这个会话ID发送到服务器我就知道你是谁了。 分布式session问题: 1粘性session以Nginx为例在upstream模块配置ip_hash单个ip的请求永远到同一台服务器上。 2session复制tomcat支持配置 3session共享保存在第三方中间件比如redis项目引入spring session和redis后直接操作HttpSession就可以实现。
总结 1session 在服务器端cookie 在客户端浏览器 2session 默认被存在服务器的一个文件里也可以是内存中比如redis 3session 的运行依赖 session id而 session id 是存在 cookie 中的也就是说如果浏览器禁用了 cookie 同时 session 也会失效但是可以通过其它方式实现比如在 url 中传递 session_id。 4session 可以放在 文件、数据库、或内存中都可以Cookie是保存在浏览器上的一些数据一般通过HTTP响应头set cookie来设置。 5用户验证这种场合一般会用 session。 链接 分布式sessionhttps://developer.aliyun.com/article/842002 https://www.cnblogs.com/lansetiankongblog/p/10833485.html讲的比较复杂 TCP的三次握手和四次挥手
先理解基本的步骤之后思考两个问题
为什么不可以两次握手为什么挥手比握手多一次
弄懂这两个问题TCP连接的知识点就算理解了。
整体流程 三次握手
数据序号16位表示在这个报文段中的第一个数据字节序号 确认序号仅当ACK标志为1时有效确认号表示期望收到的下一个字节的序号
1客户端发送一个SYN段并指明客户端的初始序列号ISN©。 2服务端发送自己的SYN段作为应答同样指明自己的序号和确认号。为了确认客户端的SYN将ISN©1作为ACK数值。这样每发送一个SYN序列号就会加1。如果有丢失的情况则会重传。 3为了确认服务器端的SYN客户端将ISN(s)1作为返回的ACK数值。
如果全连接池满了会发生什么
从服务端来说三次握手中第一步server接受到client的syn后把相关信息放到半连接队列中同时回复synack给client. 第三步当收到客户端的ack, 将连接加入到全连接队列。
一般全连接队列比较小会先满此时半连接队列还没满。如果这时收到syn报文则会进入半连接队列没有问题。但是如果收到了三次握手中的第3步(ACK)则会根据tcp_abort_on_overflow字段来决定是直接丢弃还是直接reset。此时客户端发送了ACK, 那么客户端认为三次握手完成它认为服务端已经准备好了接收数据的准备。但此时服务端可能因为全连接队列满了而无法将连接放入会重新发送第2步的synack, 如果这时有数据到来服务器TCP模块会将数据存入队列中。一段时间后client端没收到回复超时连接异常client会主动关闭连接。
为什么要三次握手
三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的
第一次握手发送端什么都确认不了接收端对方发送正常自己接受正常第二次握手发送端对方发送接受正常自己发送接受正常 接收端对方发送正常自己接受正常第三次握手发送端对方发送接受正常自己发送接受正常接收端对方发送接受正常自己发送接受正常
两次握手为什么不行呢会产生什么问题
两次握手也是不可靠的比如client发出的第一个连接请求报文段并没有丢失而是在某个网络结点长时间的滞留了以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段同意建立连接。如果只有两次握手client不会发送数据但server会误以为新的连接已经建立并一直等待client发来数据。这种状态叫做半连接server的很多资源就白白浪费掉了。
建立半连接资源浪费老的数据被当成新的数据接收了
但如果采用三次握手client不会向server的确认发出确认。server由于收不到确认就知道client并没有要求建立连接。
TCP三次握手中最后一次回复丢失会发生什么
如果最后一次ACK在网络中丢失那么Server端服务端该TCP连接的状态仍为SYN_RECV并且根据 TCP的超时重传机制依次等待3秒、6秒、12秒后重新发送 SYNACK 包以便 Client客户端重新发送ACK包 如果重发指定次数后仍然未收到ACK应答那么一段时间后Server服务端自动关闭这个连接 但是Client客户端认为这个连接已经建立如果Client客户端端向Server服务端发送数据Server端服务端将以RST包Reset标示复位用于异常的关闭连接响应此时客户端知道第三次握手失败 四次挥手 1客户端发送一个FIN段并包含一个希望接收者看到的自己当前的序列号K. 同时还包含一个ACK表示确认对方最近一次发过来的数据发送消息后会进入 FIN_WAIT_1 状态 2服务端将K值加1作为ACK序号值表明收到了上一个包会进入 CLOSE_WAIT 状态并向客户端发送 ACK 消息 3客户端接收到 ACK 消息时会进入 FIN_WAIT_2 状态 4当服务端没有待发送的数据时服务端会向客户端发送 FIN 消息ACKK1, SeqL 5客户端接收到 FIN 消息后会进入 TIME_WAIT 状态并向服务端发送 ACK 消息ACKL1。 6服务端收到后会进入 CLOSED 状态 7客户端等待两个最大数据段生命周期Maximum segment lifetimeMSL2的时间后也会进入 CLOSED 状态。
为什么建立连接是三次握手而关闭连接却是四次挥手呢
这是因为服务端在LISTEN状态下收到建立连接请求的SYN报文后把ACK和SYN放在一个报文里发送给客户端。而关闭连接时当收到对方的FIN报文时仅仅表示对方不再发送数据了但是还能接收数据己方是否现在关闭发送数据通道需要上层应用来决定因此己方ACK和FIN一般都会分开发送。 链接 https://zhuanlan.zhihu.com/p/53374516 https://www.nowcoder.com/discuss/353157350951428096 https://juejin.cn/post/6844903548862513159 syn flood攻击
如果恶意向某个服务器端口发送大量的SYN包则可以使服务器打开大量的半连接分配TCBTransmission Control Block, 从而消耗大量的服务器资源同时也使得正常的连接请求无法被响应造成服务瘫痪。
七层OSI模型TCP/IP协议模型
这部分需要了解各层分别实现了什么协议并深入理解每层至少一个协议。
应用层协议
协议全称DNS域名解析HTTPHypertext Transfer Protocol 超文本传输协议DHCP动态主机分配协议FTPFile Transfer Protocol 文件传输协议SMTPSimple Mail Transfer Protocol 即简单邮件传输协议SSHSecure Shell 安全外壳协议TELNET远程登录协议RPCRemote Procedure Call Protocol 远程过程调用协议POP3Post Office Protocol 3 即邮局协议的第3个版本TLSTransport Layer Security Protocol 安全传输层协议
DHCP通常被用于局域网环境主要作用是集中的管理、分配IP地址使client动态的获得IP地址、Gateway地址、DNS服务器地址等信息并能够提升地址的使用率。简单来说DHCP就是一个不需要账号密码登录的、自动给内网机器分配IP地址等信息的协议。
传输层协议
协议全称TCPTransmission Control Protocol传输控制协议UDP(User Datagram Protocol用户数据报协议DCCPDatagram Congestion Control Protocol数据报拥塞控制协议
DCCP数据报拥塞控制协议是一个可以进行拥塞控制的非可靠传输协议并同时提供多种拥塞控制机制在通信开始时由用户进行协商选择。可以 建立、维护和拆卸不可靠连接的数据流以及对不可靠性数据流进行拥塞控制。
网络层协议
协议全称描述IP(IPv4 · IPv6) Internet Protocol网络之间互连的协议ARPAddress Resolution Protocol即地址解析协议实现通过IP地址得知其MAC物理地址。RARPReverse Address Resolution Protocol 反向地址转换协议允许局域网的物理机器从网关服务器的 ARP 表或者缓存上请求其 IP 地址。ICMPInternet Control Message ProtocolInternet控制报文协议它是TCP/IP协议族的一个子协议用于在IP主机、路由器之间传递控制消息。IGMPInternet 组管理协议IGMP是因特网协议家族中的一个组播协议用于IP 主机向任一个直接相邻的路由器报告他们的组成员情况。RIP路由信息协议RIP是一种在网关与主机之间交换路由选择信息的标准。OSPFOpen Shortest Path First开放式最短路径优先
消息传送过程中可能会因为发送消息太长或者数据包无法按顺序到达等原因造成问题。在这种情况下接收方使用 ICMP 向发送方发送错误消息并请求重新发送消息。
ICMP协议最常用于生成错误报告和诊断上。比如ICMP 错误消息报告网络错误例如目的地不可达、超时或分段问题。如果发生这种情况接收方会将 ICMP 错误报告消息发回给发送方。
ping 命令是基于 ICMP 协议来工作的。ping 命令会发送一份ICMP回显请求报文给目标主机并等待目标主机返回ICMP回显应答。因为ICMP协议会要求目标主机在收到消息之后必须返回ICMP应答消息给源主机如果源主机在一定时间内收到了目标主机的应答则表明两台主机之间网络是可达的。
traceroute命令利用ICMP 协议定位你的计算机和目标计算机之间的所有路由器。TTL 值可以反映数据包经过的路由器或网关的数量数据包每通过一个路由器该值就会减 1。当数据包到达 TTL 为零的路由器时路由器会向源端发送一条 ICMP 消息。通过操纵独立ICMP 呼叫报文的TTL time to live值和观察该报文被抛弃的返回信息traceroute命令能够遍历到数据包传输路径上的所有路由器。 链接https://zhuanlan.zhihu.com/p/45110873 各种io模型的知识
五种IO模型
* 阻塞IOblocking IO
* 非阻塞IOnonblocking IO
* IO多路复用IO multiplexing
* 信号驱动IO (signal driven IO
前四种都属于同步IO
* 异步IO (asynchronous IO1. 阻塞IOblocking IO 对于一个network IO (这里我们以read举例)它会涉及到两个系统对象一个是调用这个IO的process (or thread)另一个就是系统内核(kernel)。当一个read操作发生时它会经历两个阶段 1等待数据准备 (Waiting for the data to be ready) 2将数据从内核拷贝到进程中(Copying the data from the kernel to the process) 单线程连接实例
大部分的socket接口都是阻塞型的。所谓阻塞型接口是指系统调用一般是IO接口不返回调用结果并让当前线程一直阻塞只有当该系统调用获得结果或者超时出错时才返回所以线程发起系统调用时本身都是阻塞的。如何改进呢顺其自然可以想到多进程实现各进程或线程间互不干扰。 多线程连接实例
输入参数s是从socket()bind()和listen()中沿用下来的socket句柄值。执行完bind()和listen()后操作系统已经开始在指定的端口处监听所有的连接请求如果有请求则将该连接请求加入请求队列。调用accept()接口正是从 socket s 的请求队列抽取第一个连接信息创建一个与s同类的新的socket返回句柄。新的socket句柄即是后续read()和recv()的输入参数。如果请求队列当前没有请求则accept() 将进入阻塞状态直到有请求进入队列。
非阻塞IOnonblocking IO 从图中可以看出当用户进程发出read操作时如果kernel中的数据还没有准备好那么它并不会block用户进程而是立刻返回一个error。从用户进程角度讲 它发起一个read操作后并不需要等待而是马上就得到了一个结果。用户进程判断结果是一个error时它就知道数据还没有准备好于是它可以再次发送read操作。一旦kernel中的数据准备好了并且又再次收到了用户进程的system call那么它马上就将数据拷贝到了用户内存然后返回。
IO多路转接IO multiplexing
当用户进程调用了select那么整个进程会被block而同时kernel会“监视”所有select负责的socket当任何一个socket中的数据准备好了select就会返回。这个时候用户进程再调用read操作将数据从kernel拷贝到用户进程。
在多路复用模型中对于每一个socket一般都设置成为non-blocking但是如上图所示整个用户的process其实是一直被block的。只不过process是被select这个函数block而不是被socket IO给block。因此select()与非阻塞IO类似。
异步IO (asynchronous IO
用户进程发起read操作之后立刻就可以开始去做其它的事。而另一方面从kernel的角度当它受到一个asynchronous read之后首先它会立刻返回所以不会对用户进程产生任何block。然后kernel会等待数据准备完成然后将数据拷贝到用户内存当这一切都完成之后kernel会给用户进程发送一个signal告诉它read操作完成了。
非阻塞IO与异步IO的区别
两者的区别就在于synchronous IO做IO operation的时候会将process阻塞。按照这个定义之前所述的blocking IOnon-blocking IOIO multiplexing都属于synchronous IO。定义中所指的”IO operation”是指真实的IO操作就是例子中的recvfrom这个系统调用。non-blocking IO在执行recvfrom这个系统调用的时候如果kernel的数据没有准备好这时候不会block进程。但是当kernel中数据准备好的时候recvfrom会将数据从kernel拷贝到用户内存中这个时候进程是被block了在这段时间内进程是被block的。而asynchronous IO则不一样当进程发起IO操作之后就直接返回再也不理睬了直到kernel发送一个信号告诉进程说IO完成。在这整个过程中进程完全没有被block。
http协议和tcp协议的区别
TCP协议对应于传输层主要解决数据如何在网络中传输而HTTP协议对应于应用层主要解决如何封装数据。从本质上来说二者没有可比性。Http协议是建立在TCP协议基础之上的当浏览器需要从服务器获取网页数据的时候会发出一次Http请求。Http会通过TCP建立起一个到服务器的连接通道当本次请求的数据完毕后Http会立即将TCP连接断开。 链接 https://www.nowcoder.com/discuss/353157349772828672 https://www.jianshu.com/p/947a2673102a一般随便看看即可 https和http的区别
HTTPS 协议基于ssl层的超文本传输协议HyperText Transfer Protocol over Secure Socket Layer一般理解为Https Http SSL通过 SSL证书来验证服务器的身份并为浏览器和服务器之间的通信进行加密保证数据安全性、报文完整性、身份验证机制。 基本流程
首先客户端通过URL访问服务器建立SSL连接。服务端收到客户端请求后会将网站支持的证书信息证书中包含公钥传送一份给客户端。客户端的服务器开始协商SSL连接的安全等级也就是信息加密的等级。客户端的浏览器根据双方同意的安全等级建立会话密钥然后利用网站的公钥将会话密钥加密并传送给网站。服务器利用自己的私钥解密出会话密钥。服务器利用会话密钥加密与客户端之间的通信。 2. 详细过程 完全理解以上过程需要知道三个概念对称加密非对称加密和数字证书 通信双方通过对称加密来加密密文然后使用非对称加密的方式来传递对称加密所使用的密钥。这样效率对称加密通信和安全非对称加密传递密钥就都能保证了。
第一步Alice给出自己支持的SSL协议版本号一个客户端随机数(Client random请注意这是第一个随机数)客户端支持的加密方法等信息发送给Bob第二步Bob收到信息后确认双方使用的加密方法并返回数字证书一个服务器生成的随机数(Server random注意这是第二个随机数)等信息第三步Alice确认数字证书的有效性然后生成一个新的随机数(Premaster secret)然后使用数字证书中的公钥加密这个随机数发给Bob。第四步Bob使用自己的私钥获取A发来的随机数(即Premaster secret) (以上的第三、四步就是非对称加密的过程了)第五步Alice和Bob通过约定的加密方法(通常是AES算法)使用前面三个随机数生成对话密钥用来加密接下来的通信内容(之后就是对称加密了) 链接https://juejin.cn/post/6844903602494898183 为了防止中间有人对证书内容进行更改有了一个数字签名的概念所谓的数字签名就是把以上所有的内容做一个Hash操作信息摘要算法得到一个固定长度然后再传给Bob。然而如果别人截取了这个证书然后更改内容同时生成了新的Hash值那怎么办处于这个考虑CA机构在颁发这个证书的时候会用自己的私钥将Hash值摘要加密从而防止了数字证书被篡改。
服务端Bob和客户端Alice通信保证数据完整性也是这个思路假设Alice已经成功拿到Bob的公钥这时Bob可以用MD5或者SHA-1信息摘要算法将数据编码之后用自己的私钥加密并将加密后的内容和数据一起发给AliceAlice可以用公钥验证发送者身份是不是Bob基本逻辑是可以用Bob的公钥还原Bob私钥加密的数据则发送者必持有Bob私钥且只有Bob有自己的私钥所以发送者是Bob。
至于这个公钥怎么安全可靠的到Alice手中则又是另一个故事了。主要是通过CA第三方来保证的。CA的公钥通过带外的方式比如安装操作系统或者浏览器时就已经安装好了之后CA会用自己的私钥将发送者实体和它的公钥加密相当于一个签名之后接收者可以用CA的公钥解开取到对方的公钥完成前述的一系列通信流程。
HTTPS缺点
HTTPS协议多次握手导致页面的加载时间延长近50%HTTPS连接缓存不如HTTP高效会增加数据开销和功耗申请SSL证书需要钱功能越强大的证书费用越高。SSL涉及到的安全算法会消耗 CPU 资源对服务器资源消耗较大。
非对称加密算法RSA算法 该算法基于一个十分简单的数论事实将两个大素数相乘十分容易但想要对其乘积进行因式分解却极其困难因此可以将乘积公开作为加密密钥即公钥而两个大素数组合成私钥。
非对称加密算法涉及到大数乘法和求余计算成本是比较高的不适合作为长期会话密钥。对称密钥算法主要是位运算成本较低。 感兴趣的可以去阅读加密算法原理【非对称加密算法RSA算法】【对称加密算法DES】【哈希算法】 以下根据郑铨老师课程截图补充
1身份认证 安全漏洞可以被中间方截获并伪造密钥根源在于bob无法可靠拿到Alice的公钥。如何解决这个问题放在第三部分说明了。 2报文完整性
通过数字签名保证报文完整性。大致原理如下但是一般加密的内容是经过信息摘要算法得到的~128bit固定长度的摘要比如MD5或者SHA-1算法是一种特殊的哈希算法。 3数据安全性
最根本的需求是Alice和Bob建立可信任的通信关系所以两者必须共同信任一个可信赖的第三方。两个场景分别是对称密钥的分发问题和公共密钥的分发问题。 前提条件是Alice和Bob已经分别与KDC建立了可依赖的通信关系。 前提条件是Alice和Bob已经通过带外方式分别拿到了CA的公钥比如安装操作系统时就已经附带证书。 补充信任树的概念
lvsnginxHAProxy
先给结论LVS传输层、Nginx应用层、HAProxy应用层 是目前使用最广泛的三种软件负载均衡软件。
传输层实现方式
通过报文中的IP地址和端口再加上负载均衡设备所采用的负载均衡算法最终确定选择后端哪台下游服务器。以TCP为例客户端向负载均衡发送SYN请求建立第一次连接通过配置的负载均衡算法选择一台后端服务器并且将报文中的IP地址信息修改NAT或直接路由为后台服务器的IP地址信息因此TCP三次握手连接是与后端服务器直接建立起来的。
传输层实现缺点
四层负载均衡与服务器直接建立起TCP连接很容易遭受SYN Flood攻击。SYN Flood是一种广为人知的DDoS分布式拒绝服务攻击的方式这是一种利用TCP协议缺陷发送大量伪造的TCP连接请求从而使得被攻击方资源耗尽的攻击方式。从技术实现原理上可以看出四层负载均衡很容易将垃圾流量转发至后台服务器而七层设备则可以过滤这些恶意并清洗这些流量但要求设备本身具备很强的抗DDOS流量的能力。但是四层负载均衡的负载更高。
LVS (Linux Virtual Server) LVS 架设的服务器集群系统有三个部分组成
(1) 最前端的负载均衡层用 Load Balancer 表示
(2) 中间的服务器集群层用 Server Array 表示
(3) 最底端的数据共享存储层用 Shared Storage 表示
LVS 是四层负载均衡也就是说建立在 OSI 模型的传输层之上传输层上有我们熟悉的 TCP/UDPLVS 支持 TCP/UDP 的负载均衡但 URL 解析等工作LVS 无法完成。
nginx
Nginx 负载均衡主要是对七层网络通信模型中的第七层应用层上的 http、https 进行支持。
Nginx 是以反向代理的方式进行负载均衡的。反向代理Reverse Proxy方式是指以代理服务器来接受 Internet 上的连接请求然后将请求转发给内部网络上的服务器并将从服务器上得到的结果返回给 Internet 上请求连接的客户端此时代理服务器对外就表现为一个服务器。
Nginx 实现负载均衡的分配策略有很多Nginx 的 upstream 目前支持以下几种方式 轮询默认每个请求按时间顺序逐一分配到不同的后端服务器如果后端服务器 down 掉能自动剔除。 weight指定轮询几率weight 和访问比率成正比用于后端服务器性能不均的情况。 ip_hash每个请求按访问 ip 的 hash 结果分配这样每个访客固定访问一个后端服务器可以解决 session 的问题。 fair第三方按后端服务器的响应时间来分配请求响应时间短的优先分配。 url_hash第三方按访问 url 的 hash 结果来分配请求使每个 url 定向到同一个后端服务器后端服务器为缓存时比较有效。
HAProxy
HAProxy 支持两种代理模式 TCP四层和HTTP七层也是支持虚拟主机的。
HAProxy 的优点能够补充 Nginx 的一些缺点比如支持 Session 的保持Cookie 的引导同时支持通过获取指定的 url 来检测后端服务器的状态。
HAProxy 跟 LVS 类似本身就只是一款负载均衡软件单纯从效率上来讲 HAProxy 会比 Nginx 有更出色的负载均衡速度在并发处理上也是优于 Nginx 的。
TCP和UDP的区别
1、基于连接与无连接
2、对系统资源的要求TCP较多UDP少
3、UDP程序结构较简单
4、流模式与数据报模式
5、TCP保证数据正确性UDP可能丢包
6、TCP保证数据顺序UDP不保证。 链接https://zhuanlan.zhihu.com/p/24860273 如何实现UDP的可靠传输
在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理。
可靠UDP的简单设计
1、添加seq/ack机制确保数据发送到对端 2、添加发送和接收缓冲区主要是用户超时重传。 3、添加超时重传机制。
详细说明发送端发送数据时生成一个随机seqx然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存并发送一个ackx的包表示对方已经收到了数据。发送端收到了ack包后删除缓冲区对应的数据。时间到后定时任务检查是否需要重传数据
举例UDT(UDP-based Data Transfer Protocol)、KCP
TCP如何实现可靠传输
TCP协议保证数据传输可靠性的方式主要有
1校验和 2序列号确认应答
3超时重传
接收方发现接收的数据已存在判断存在的根据就是序列号就会丢弃包并重发ACK如果指数累积等待时间大约1分钟还是没有接收到ACK发送方就认为网络或者对端出现异常强制关闭连接。
4三次握手四次挥手 5流量控制
如果发送者发送数据过快接收者来不及接收那么就会有分组丢失。为了避免分组丢失控制发送者的发送速度使得接收者来得及接收这就是流量控制。
由滑动窗口协议连续ARQ协议实现。滑动窗口协议既保证了分组无差错、有序接收也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小并且利用大小来控制发送方的数据发送。
补充下自动重传请求Automatic Repeat-reQuestARQ自动重传请求 ARQ 包括了停止等待协议、回退 N 步协议和选择重传协议后两种结合了窗口机制属于连续 ARQ 协议。
停止等待协议回退N步重传(Go-Back-N)
接收点丢弃从第一个没有收到的数据包开始的所有数据包。发送点收到ACK后从ACK中指明的数据包开始重新发送。在 GBN 协议中接收方丢弃所有失序分组即使是正确接收的也要丢弃这样做的理由是接收方必须按序将数据交付给上层。
选择重传(Selective Repeat)
发送点连续发送数据包但对每个数据包都设有个一个计时器。当在一定时间内没有收到某个数据包的ACK时发送点只重新发送那个没有ACK的数据包。 链接 https://www.nowcoder.com/discuss/353156544944611328 https://blog.csdn.net/liuchenxia8/article/details/80428157 6拥塞控制
拥塞控制是作用于网络的它是防止过多的数据注入到网络中避免出现网络负载过大的情况常用的方法就是 网络辅助的拥塞控制 网络辅助的拥塞控制根据网络反馈计算最小带宽由网络反馈发送方。对网络负载压力比较大TCP使用端到端的拥塞控制。
拥塞感知
轻微拥塞 和 拥塞 两种情况 reno算法
慢开始、拥塞避免 快重传、快恢复
发送方维持一个叫做拥塞窗口cwndcongestion window的状态变量。拥塞窗口的大小取决于网络的拥塞程度并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口另外考虑到接受方的接收能力发送窗口可能小于拥塞窗口。 慢启动 为了防止cwnd增长过大引起网络拥塞还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下当cwndssthresh时使用慢开始算法。当cwndssthresh时改用拥塞避免算法。 拥塞避免
拥塞避免算法让拥塞窗口缓慢增长即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。
AIMD算法乘法减小Multiplicative Decrease和加法增大Additive Increase算法。 “乘法减小”指的是无论是在慢开始阶段还是在拥塞避免阶段只要发送方判断网络出现拥塞就把慢开始门限ssthresh设置为出现拥塞时的发送窗口大小的一半并执行慢开始算法所以当网络频繁出现拥塞时ssthresh下降的很快以大大减少注入到网络中的分组数。“加法增大”是指执行拥塞避免算法后使拥塞窗口缓慢增大以防止过早出现拥塞。 快重传Reno算法改进
快重传要求接收方在收到一个失序的报文段后就立即发出重复确认为的是使发送方及早知道有报文段没有到达对方可提高网络吞吐量约20%而不要等到自己发送数据时捎带确认。快重传算法规定发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段而不必继续等待设置的重传计时器时间到期。 快恢复
考虑到如果网络出现拥塞的话就不会收到好几个重复的确认所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法而是将cwnd设置为ssthresh减半后的值33个冗余ack然后执行拥塞避免算法使cwnd缓慢增大。 总结 链接 https://zhuanlan.zhihu.com/p/37379780 一次RPC调用的整个调用链路 (1) 客户端client以本地调用方式即以接口的方式调用服务
以下对用户透明 (2) 客户端存根client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体将消息体对象序列化为二进制 (3) 客户端通过sockets将消息发送到服务端 (4) 服务端存根( server stub收到消息后进行解码将消息对象反序列化 (5) 服务端存根( server stub根据解码结果调用本地的服务 (6) 本地服务执行并将结果返回给服务端存根( server stub (7) 服务端存根( server stub将返回结果打包成消息将结果消息对象序列化 (8) 服务端server通过sockets将消息发送到客户端* (9) 客户端存根client stub接收到结果消息并进行解码将结果消息反序列化* 以上对用户透明
(10) 客户端client得到最终结果。
RPC的目标是要把2、3、4、7、8、9这些步骤都封装起来。 链接 RPC教程https://blog.csdn.net/qq_40856284/category_10138756.html https://blog.csdn.net/heyeqingquan/article/details/78006587 http restful 和 RPC的区别各自适用的场景
所属类别不同
REST 是一种软件架构风格。这种风格的典型应用就是HTTP。其因为简单、扩展性强的特点而广受开发者的青睐。
而RPC 呢是 Remote Procedure Call Protocol 的简写中文描述是远程过程调用它可以实现客户端像调用本地服务(方法)一样调用服务器的服务(方法)。 RPC 可以基于 TCP/UDP也可以基于 HTTP 协议进行传输的。
使用方式不同
从使用上来看HTTP 接口只关注服务提供方对于客户端怎么调用并不关心。接口只要保证有客户端调用时返回对应的数据就行了。而RPC则要求客户端接口保持和服务端的一致。
REST 是服务端把方法写好客户端并不知道具体方法。客户端只想获取资源所以发起HTTP请求而服务端接收到请求后根据URI经过一系列的路由才定位到方法上面去RPC是服务端提供好方法给客户端调用客户端需要知道服务端的具体类具体方法然后像调用本地方法一样直接调用它。
面向对象不同
从设计上来看RPC所谓的远程过程调用 是面向方法的 REST所谓的 Representational state transfer 是面向资源的除此之外还有一种叫做 SOA所谓的面向服务的架构它是面向消息的。
序列化协议不同
接口调用通常包含两个部分序列化和通信协议。
通信协议上面已经提及了REST 是 基于 HTTP 协议而 RPC 可以基于 TCP/UDP也可以基于 HTTP 协议进行传输的。
常见的序列化协议有json、xml、hession、protobuf、thrift、text、bytes等REST 通常使用的是 JSON或者XML而 RPC 使用的是 JSON-RPC或者 XML-RPC。
应用场景
REST和RPC都常用于微服务架构中。
1HTTP相对更规范更标准更通用无论哪种语言都支持http协议。如果你是对外开放API例如开放平台外部的编程语言多种多样你无法拒绝对每种语言的支持现在开源中间件基本最先支持的几个协议都包含RESTful。
2RPC 框架作为架构微服务化的基础组件它能大大降低架构微服务化的成本提高调用方与服务提供方的研发效率屏蔽跨进程调用函数服务的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。
总结
RPC 和 REST 两者的定位不同REST 面向资源更注重接口的规范因为要保证通用性更强所以对外最好通过 REST。而 RPC 面向方法主要用于函数方法的调用可以适合更复杂通信需求的场景。RESTful API客户端与服务端之间采用的是同步机制当发送HTTP请求时客户端需要等待服务端的响应。当然对于这一点是可以通过一些技术来实现异步的机制的。采用RESTful API客户端与服务端之间虽然可以独立开发但还是存在耦合。比如客户端在发送请求的时必须知道服务器的地址且必须保证服务器正常工作。而 rpc rabbitmq中间件可以实现低耦合的分布式集群架构。
DNS协议用到了什么传输层协议
DNS在区域传输的时候使用TCP协议域名解析时使用UDP协议。 DNS区域传输的时候使用TCP协议辅域名服务器会定时一般3小时向主域名服务器进行查询以便了解数据是否有变动。如有变动会执行一次区域传送进行数据同步。区域传送使用TCP因为数据同步传送的数据量比一个请求应答的数据量要多得多需要保证数据的准确性。 DNS域名解析时使用UDP协议作为传输层协议的主要原因是为了避免使用 TCP 协议时造成的连接时延减小用户的响应时间。
为了得到一个域名的 IP 地址往往会向多个域名服务器查询如果使用 TCP 协议那么每次请求都会存在连接时延这样使 DNS 服务变得很慢因为大多数的地址查询请求都是浏览器请求页面时发出的这样会造成网页的等待时间过长。
但是使用 UDP 协议作为 DNS 协议也会有一个问题由于历史原因物理链路的最小MTU 576所以为了限制报文长度不超过576UDP 的报文段的长度被限制在 512 个字节以内这样一旦 DNS 的查询或者应答报文超过了 512 字节那么基于 UDP 的DNS 协议就会被截断为 512 字节那么有可能用户得到的 DNS 应答就是不完整的。这里 DNS 报文的长度一旦超过限制并不会像 TCP 协议那样被拆分成多个报文段传输因为 UDP 协议不存在报文ID因而不会维护连接状态所以我们没有办法确定那几个报文段属于同一个数据UDP 只会将多余的数据给截取掉。为了解决这个问题我们也可以使用 TCP 协议去请求报文。
补充新电脑如何获取网关地址
对于自己网段内的网关可以通过ARP广播的方式获取MAC地址。否则需要交由下一级路由表去查再返回给自己。这里有一个所谓ARP攻击的概念有兴趣的读者可以去了解。
服务端出现大量TIME_WAIT是什么原因导致的
time_wait状态必要性
1防止延迟的数据段被其他使用相同源地址、源端口、目的地址以及目的端口的 TCP 连接误接收 2保证 TCP 连接的远程被正确关闭即等待 被动关闭连接的一方收到 FIN 对应的 ACK 消息
大量time_wait原因
在高并发短连接的TCP服务器上当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高此时部分客户端就会显示连接不上。主动正常关闭TCP连接都会出现TIME_WAIT。
为什么我们要关注这个高并发短连接呢有两个方面需要注意
高并发可以让服务器在短时间范围内同时占用大量端口而端口有个0~65535的范围并不是很多刨除系统和其他服务要用的剩下的就更少了。在这个场景中短连接表示“业务处理传输数据的时间远远小于TIME_WAIT超时的时间”的连接。
这里有个相对长短的概念比如取一个web页面1秒钟的http短连接处理完业务在关闭连接之后这个业务用过的端口会停留在TIME_WAIT状态几分钟而这几分钟其他HTTP请求来临的时候是无法占用此端口的。单用这个业务计算服务器的利用率会发现服务器干正经事的时间和端口资源被挂着无法被使用的时间的比例是 1几百服务器资源严重浪费。
解决
允许time_wait状态的socket被重用。【打开系统的TIME_WAIT重用和快速回收】用负载均衡来抗这些高并发的短请求使用长连接【HTTP请求头connection设置为keep-alive】强制关闭发送 RST 包越过TIMEWAIT状态直接进入CLOSED状态增加端口… 链接https://www.cnblogs.com/dadonggg/p/8778318.html
