1.POST和GET的区别

  1. GET和POST本质上就是TCP链接,并无差别
  2. GET,它用于获取信息,它只是获取、查询数据,也就是说它不会修改服务器上的数据,从这点来讲,它是数据安全的。例如获取更新的20条微博。
  1. Post,向指定的资源提交要被处理的数据,它是可以向服务器发送修改请求,从而修改服务器的,比如微博的点赞、评论操作,这就要用到Post了,当然它也是可以仅仅获取数据的。由于它可以修改服务器数据,所以这是数据不安全的
  2. GET后退按钮/刷新无害,POST数据会被重新提交(浏览器应该告知用户数据会被重新提交)。
  3. GET书签可收藏,POST为书签不可收藏。
  4. GET能被缓存,POST不能缓存 。
  5. GET编码类型application/x-www-form-url,POST编码类型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
  6. GET历史参数保留在浏览器历史中。POST参数不会保存在浏览器历史中。
  7. GET对数据长度有限制,当发送数据时,GET 方法向 URL 添加数据;URL 的长度是受限制的(URL 的最大长度是 2048 个字符)。POST无限制。url 长度限制是某些浏览器和服务器的限制,和 HTTP 协议没有关系。
  8. GET只允许 ASCII 字符。POST没有限制。也允许二进制数据。
  9. 与 POST 相比,GET 的安全性较差,因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET !POST 比 GET 更安全,因为参数不会被保存在浏览器历史或 web 服务器日志中。当然这只是相对安全,从传输的角度来说,他们都是不安全的,因为HTTP在网络上都是明文传输的,只要在网络节点上捉包,就能完整的获取数据报文。想要安全的传输,就只有加密,使用HTTPS。
  10. GET的数据在 URL 中对所有人都是可见的。POST的数据不会显示在 URL 中。
  11. 在带参数的报文中,Get方法的参数应该放在url中,其报文主体没有任何语义,Post方法的请求数据(参数)则放在报文主体中。

2.高性能网络通信库中为何要将侦听 socket 设置成非阻塞的?

我们知道如果需要使用 IO 复用函数统一管理各个 fd,需要将 clientfd 设置成非阻塞的,那么listenfd一定要设置成非阻塞的吗?答案是不一定的——只要不用IO复用函数去管理listenfd就可以了,listenfd 如果不设置成非阻塞的,那么accept函数在没有新连接时就会阻塞。

具体→https://my.oschina.net/balloonwj/blog/4403535/print

3.UDP 与 TCP 比较

TCP:

为应用层提供可靠的、面向连接的和基于流的服务。使用超时重传、数据确认等方式来确保数据包被正确地发送至目的端,因此服务是可靠的。

UDP:

则与TCP想反,它为应用层提供不可靠、无连接和基于数据报的服务。“不可靠”意味着UDP协议无法保证数据从发送端正确地传送到目的端。如果数据在途中丢失,或者目的端通过数据校验发现数据错误而将其丢弃,则UDP协议只是简单地通知应用程序发送失败。

什么时候该使用TCP:

当对网络通讯质量有要求的时候,比如:整个数据要准确无误的传递给对方,这往往用于一些要求可靠的应用,

什么时候使用UDP:

当对网络通讯质量要求不高的时候,要求速度尽可能的快,这时就可以使用UDP。

4.TCP可靠传输原理

1
2
3
4
5
ARQ(Automatic Repeat-reQuest)(自动重传请求)

- 停止等待ARQ协议

- 连续ARQ协议

停止等待ARQ协议

全双工通信的双发既是发送方也是接收方。下面为了讨论问题的方便,我们仅考虑A发送数据而B接受数据并发送确认。因此A就做发送方,B叫做接收方。因为这里是讨论可靠传输的原理,因此把传送的数据单元都称为分组,而并不考虑数据在哪一层次上传送的。停止等待就是每发送完一个分组就停止发送,等待对方的确认。在收到确认后在发送下一个分组。

1. 无差错情况

A发送分组M1,发送完就暂停发送,等待B的确认。B收到M1就向A发送确认。A在收到了对M1的确认后,就再发送下一个分组M2

2. 出现差错

如果A发送的过程中出现差错,B在接收M1时检测出了差错,就丢弃M1,其他什么都不做(也不会通知A收到有差错的分组)。又或者A传送的过程中分组丢失了,以上这两种情况下,B不会发送任何信息。

超时重传的原理也很简单:发送方发送完一个分组后,就会设置一个超时计时器,如果超时计时器到期之前没有收到接收方发来的确认信息,则会重发刚发送过的分组;如果收到确认信息,则撤销该超时计时器。

这里应该注意的是:

  1. 既然发送方发送的分组可能丢失或者有差错,可能需要重传,那么它必须暂时保留已发送的分组副本,只有收到确认后,才清除这个副本。
  2. 分组和确认分组信息都应该有各自的编号,用来标示每一个分组和确认信息。(这样才知道需要发送哪个分组,收到了哪个分组的确认信息)
  3. 超时计时器设置的时间应该略长于分组传送往返时间

3. 确认丢失和确认迟到

像上述这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest),ARQ 表明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组 。

流水线传输

这种停止等待协议的优点是简单,但缺点是信道利用率太低,传输效率不高。

流水线传输:

  • 发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。
  • 由于信道上一直有数据不间断地传送,这种传输方式可获得很高的信道利用率。


当使用流水线传输时,就要使用下面介绍的连续ARQ协议和滑动窗口协议。

连续 ARQ 协议

下图表示发送方维持的发送窗口,他的意义是:位于发送窗口内的5个分组都可以连续发送出去,而不需要等待对方的确认。这样信道利用率就提高了。

连续ARQ协议规定,发送方每接收到一个确认,就把发送窗口向前滑动一个分组的位置。下图表示发送方收到了第一个分组的确认,于是把发送窗口向前移动一个分组的位置。

如果原来已经发送了前5个分组,那么现在就可以发送窗口内的第六个分组。

接收方一般都采用累积确认的方式。这就是说接收方不必对收到的分组逐个发送确认,而是可以在几个分组后,对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已经正确接收到了。

累积确认

  • 接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已正确收到了。
  • 累积确认有的优点是:容易实现,即使确认丢失也不必重传。缺点是:不能向发送方反映出接收方已经正确收到的所有分组的信息。

Go-back-N(回退 N)

  • 如果发送方发送了前5个分组,而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次。
  • 这就叫做 Go-back-N(回退N),表示需要再退回来重传已发送过的 N 个分组。
  • 可见当通信线路质量不好时,连续 ARQ 协议会带来负面的影响。

5.TCP 拥塞控制的作用,理解具体原理

拥塞控制:

防止过多的数据注入到网络当中,这样可以使网络中的路由器或链路不致过载。(通过拥塞窗口处理网络拥塞现象的一种机制)

拥塞控制过程(Reno算法)

将拥塞控制的过程分为四个阶段:慢启动、拥塞避免、快重传和快恢复

  • 慢启动阶段思路是不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增加拥塞窗口的大小,在没有出现丢包时每收到一个 ACK 就将拥塞窗口大小加一(单位是 MSS,最大单个报文段长度),每轮次发送窗口增加一倍,呈指数增长,若出现丢包,则将拥塞窗口减半,进入拥塞避免阶段;
  • 当窗口达到慢启动阈值或出现丢包时,进入拥塞避免阶段,窗口每轮次加一,呈线性增长;当收到对一个报文的三个重复的 ACK 时,认为这个报文的下一个报文丢失了,进入快重传阶段,要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方,可提高网络吞吐量约20%)而不要等到自己发送数据时捎带确认;
  • 快重传完成后进入快恢复阶段,将慢启动阈值修改为当前拥塞窗口值的一半,同时拥塞窗口值等于慢启动阈值,然后进入拥塞避免阶段,重复上述过程。

6.理解三次握手以及四次挥手具体过程,三次握手的原因、四次挥手原因

三次握手过程理解:

  • 标志位
    • SYN:请求建立连接
    • ACK:应答
    • FIN:断开连接

第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。

第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;

第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

四次挥手过程理解:

1.哪一端断开连接都可以

  1. 客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
  2. 服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
  3. 客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
  4. 服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
  5. 客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
  6. 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。

常见面试题

【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?

答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间(Linux下MSL是30s)。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。

【问题3】为什么不能用两次握手进行连接?

答:
3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。

【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?

TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。

7.TIME_WAIT的作用

  • 确保最后一个确认报文能够到达。如果没能到达,服务端就会重发FIN请求释放连接。等待一段时间没有收到重发就说明服务的已经CLOSE了。如果有重发,则客户端再发送一次LAST ack信号
  • 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失,使得下一个新的连接不会出现旧的连接请求报文。我们都知道的是time_wait太短或者取消,可能会使上一个连接延迟的数据包被新的连接收到,从而影响到新连接的数据。

在linux中,time_wait时间定死了为1分钟,也就是2MSL,这个时间会保证延迟的数据包在网络中消失,也会保证没有丢失的数据包在这个时间内到达指定端,所以在这个时间后不会存在上一个连接的数据包被新的连接收到的情况了。

TCP必须防止来自之前那个连接的老的重复分组在新连接上出现。为了做到这一点,TCP将不复用处于TIME_WAIT状态的连接。

8.HTTP协议

HTTP协议是超文本传输协议的缩写,英文是Hyper Text Transfer Protocol。它是从WEB服务器传输超文本标记语言(HTML)到本地浏览器的传送协议。

HTTP是一个基于TCP/IP通信协议来传递数据的协议,传输的数据类型为HTML 文件,、图片文件, 查询结果等。

HTTP协议一般用于B/S架构()。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。

HTTP特点

  1. http协议支持客户端/服务端模式,也是一种请求/响应模式的协议。
  2. 简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。
  3. 灵活:HTTP允许传输任意类型的数据对象。传输的类型由Content-Type加以标记。
  4. 无连接:限制每次连接只处理一个请求。服务器处理完请求,并收到客户的应答后,即断开连接,但是却不利于客户端与服务器保持会话连接,为了弥补这种不足,产生了两项记录http状态的技术,一个叫做Cookie,一个叫做Session。
  5. 无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。

更多:

https://www.cnblogs.com/an-wen/p/11180076.html

https://www.cnblogs.com/ranyonsue/p/5984001.html

9.HTTPS协议

一般http中存在如下问题:

  • 请求信息明文传输,容易被窃听截取。
  • 数据的完整性未校验,容易被篡改
  • 没有验证对方身份,存在冒充危险

什么是HTTPS?

HTTPS 协议(HyperText Transfer Protocol over Secure Socket Layer):一般理解为HTTP+SSL/TLS,通过 SSL证书来验证服务器的身份,并为浏览器和服务器之间的通信进行加密。

浏览器在使用HTTPS传输数据的流程是什么?

  1. 在百度服务器端首先生成一个秘钥对 -> 对公钥分发
  2. 百度将公钥给到了CA认证机构, ca用私钥进行签名 -> 生成了证书.
  3. 第一步第二步只做一次
  4. 客户端访问百度, 百度将ca生成的证书发送给客户端
  5. 浏览器对收到的证书进行认证
  6. 如果证书没有问题 -> 使用ca的公钥将服务器的公钥从证书中取出
  7. 我们得到了百度的公钥
  8. 在浏览器端生成一个随机数, 使用得到的公钥进行加密, 发送给服务器
  9. 服务器端使用私钥解密, 得到了随机数, 这个随机数就是对称加密的秘钥
  10. 现在秘钥分发已经完成, 后边的通信使用的的对称加密的方式

10.epoll中et和lt的区别与实现原理(重要)

(1) epoll 两种工作模式

水平触发:
内核中的socket接收缓冲区不为空,有数据可读,读事件一直触发;内核中的socket发送缓冲区不满,可以继续写入数据,写事件一直触发

边缘触发:内核中socket接收缓冲区由空变为不为空,数据由不可读变为可读,事件触发(仅一次)
内核中socket发送缓冲区由满变为不满,数据由不可写变为可写,事件触发(仅一次)。

(2) 工作模式选择时候,LT模式会一直触发可读可写事件,导致效率比较低。ET模式由于读写事件仅通知一次,可能会存在数据丢失的可能。

(3)

  1. ET模式时,当有多个连接同时到达服务器,epoll_wait会返回多个描述符,由于在ET模式下就绪状态只返回一次, 因此为了防止漏掉连接,需要循环调用accept直到接收全部连接(即返回EAGAIN错误)。
  2. ET模式时,在读写数据时,同样需要注意读写事件只触发一次的问题,若一次读或写没有处理全部数据, 则会导致数据丢失。解决办法是,accept接收连接时,设置连接的套接字为非阻塞, 并在读写数据时循环调用read/write直到数据全部处理为止(即返回EAGAIN错误)。
  3. LT模式时,若监控epoll out事件,由于内核缓冲区一开始时一直处于可写状态,会导致epoll_wait一直返回,降低效率。解决办法,
    一开始不监听out事件,直接写数据直到写缓冲区满时(即返回EAGAIN错误),再监听out事件,当数据全部写完时,就取消对out事件的监听

11.服务器端怎么判断客户端已断开连接

  1. (tcp内部机制)TCP的KeepAlive保活机制,它会先要求此连接一定时间没有活动(一般是几个小时),然后发出数据段,经过多次尝试后(每次尝试之间也有时间间隔),如果仍没有响应,则判断连接中断。可想而知,整个周期需要很长的时间。
  2. (应用层实现)一个简单的heart-beat实现一般测试连接是否中断采用的时间间隔都比较短,可以很快的决定连接是否中断。并且,由于是在应用层实现,因为可以自行决定当判断连接中断后应该采取的行为,而keepalive在判断连接失败后只会将连接丢弃。

12.TTL是什么?有什么用处

TTL是Time To Live,一般是hup count,每经过一个路由就会被减去一,如果它变成0,包会被丢掉。它的主要目的是防止包在有回路的网络上死转,浪费网络资源。

13.网络编程的一般步骤

TCP连接

  1. 服务器端1)创建套接字socket;2)绑定端口号bind;3)监听连接listen;4)接受连接请求accept,并返回新的套接字;5)用新返回的套接字recv/send;6)关闭套接字。
  2. 客户端1)创建套接字socket; 2)发起建立连接请求connect; 3)发送/接收数据send/recv;4)关闭套接字。

UDP连接

  1. 服务器端:1)创建套接字socket;2)绑定端口号bind;3)接收/发送消息recvfrom/sendto;4)关闭套接字。
  2. 客户端:1)创建套接字socket;2)发送/接收消息sendto/recvfrom;3)关闭套接字.

14.cookie和session的区别?

  1. 存在的位置:
    • cookie存在于客户端,临时文件夹中
    • session存在于服务器的内存中,一个session域对象为一个用户浏览器服务。当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用cookie。
  2. 安全性
    • cookie是以明文的方式存放在客户端的,安全性低,可以通过一个加密算法进行加密后存放
    • session存放于服务器的内存中,所以安全性好
  3. 生命周期(以20分钟为例)
    • cookie的生命周期是累计的,从创建时,就开始计时,20分钟后,cookie生命周期结束
    • session的生命周期是间隔的,从创建时,开始计时如在20分钟,没有访问session,那么session生命周期被销毁。但是,如果在20分钟内(如在第19分钟时)访问过session,那么,将重新计算session的生命周期
    • 服务器关机会造成session生命周期的结束,但是对cookie没有影响
  4. 访问范围
    • session为一个用户浏览器独享
    • cookie为多个用户浏览器共享

15.端口复用的作用

端口复用允许在一个应用程序可以把 n 个套接字绑在一个端口上而不出错。

设置socket的SO_REUSEADDR选项,即可实现端口复用:
SO_REUSEADDR可以用在以下四种情况下。

  1. 当有一个有相同本地地址和端口的socket1处于TIME_WAIT状态时,而你启动的程序的socket2要占用该地址和端口,你的程序就要用到该选项。
  2. SO_REUSEADDR允许同一port上启动同一服务器的多个实例(多个进程)。但每个实例绑定的IP地址是不能相同的。在有多块网卡或用IP Alias技术的机器可以测试这种情况。
  3. SO_REUSEADDR允许单个进程绑定相同的端口到多个socket上,但每个socket绑定的ip地址不同。这和2很相似,区别请看UNPv1。
  4. SO_REUSEADDR允许完全相同的地址和端口的重复绑定。但这只用于UDP的多播,不用于TCP

作用

端口复用最常用的用途应该是防止服务器重启时之前绑定的端口还未释放或者程序突然退出而系统没有释放端口。这种情况下如果设定了端口复用,则新启动的服务器进程可以直接绑定端口。如果没有设定端口复用,绑定会失败,提示ADDR已经在使用中。

即:当有一个有相同本地地址和端口的socket1处于TIME_WAIT状态时,而你启动的程序的socket2要占用该地址和端口,你的程序就要用到端口复用。

16.浏览器输入URL后发生了什么?

  1. DNS域名解析获取IP地址
    • 先查看浏览器dns缓存中是否有域名对应的ip。
    • 如果没有,则查看操作系统dns缓存中是否有对应的ip(例如windows的hosts文件)。
    • 查找路由器缓存(本地dns服务器):如果1,2步都查询无果,则需要借助网络,路由器一般都有自己的DNS缓存,将前面的请求发给路由器,查找ISP 服务商(互联网服务提供商)缓存 DNS的服务器,如果查找到IP则直接返回,没有的话继续查找。
    • 递归查询:如果以上步骤还找不到,则ISP的DNS服务器就会进行递归查询,所谓递归查询就是如果主机所询问的本地域名服务器不知道被查询域名的IP地址,那么本地域名服务器就以DNS客户的身份,向其他根域名服务器继续发出查询请求报文,而不是让该主机自己进行下一步查询。
    • 迭代查询:本地域名服务器采用迭代查询,它先向一个根域名服务器查询。本地域名服务器向根域名服务器的查询一般都是采用迭代查询。所谓迭代查询就是当根域名服务器收到本地域名服务器发出的查询请求报文后,告诉本地域名服务器下一步应该查询哪一个域名服务器,然后本地域名服务器自己进行后续的查询。(而不是替代本地域名服务器进行后续查询)。
  2. 浏览器与目标服务器建立TCP连接(进行三次握手)
  3. 浏览器通过http协议向目标服务器发送请求
  4. 服务器处理请求
  5. 服务器发出一个HTML响应
  6. 释放TCP连接
  7. 浏览器解析HTML
  8. 浏览器布局渲染

17.URI和URL的区别?

URI,是uniform resource identifier,统一资源标识符,用来唯一的标识一个资源。

Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的
URI一般由三部组成:

  1. 访问资源的命名机制
  2. 存放资源的主机名
  3. 资源自身的名称,由路径表示,着重强调于资源。

(注意:这只是一般URI资源的命名方式,只要是可以唯一标识资源的都被称为URI,上面三条合在一起是URI的充分不必要条件)

举例:

1
2
3
4
5
6
7
8
9
10
11
12
如:https://blog.csdn.net/qq_32595453/article/details/79516787

我们可以这样解释它:

①这是一个可以通过https协议访问的资源,

②位于主机 blog.csdn.net上,

③通过“/qq_32595453/article/details/79516787”可以对该资源进行唯一标识(注意,这个不一定是完整的路径)

注意:以上三点只不过是对实例的解释,以上三点并不是URI的必要条件,
URI只是一种概念,怎样实现无所谓,只要它唯一标识一个资源就可以了。

URL是uniform resource locator,统一资源定位器,它是一种具体的URI,即URL可以用来标识一个资源,而且还指明了如何locate这个资源。

URL是Internet上用来描述信息资源的字符串,主要用在各种WWW客户程序和服务器程序上,特别是著名的Mosaic。

采用URL可以用一种统一的格式来描述各种信息资源,包括文件、服务器的地址和目录等。URL一般由三部组成:

  1. 协议(或称为服务方式)
  2. 存有该资源的主机IP地址(有时也包括端口号)
  3. 主机资源的具体地址。如目录和文件名等

URL和URI的区别:

URI和URL都定义了资源是什么,但URL还定义了该如何访问资源。URL是一种具体的URI,它是URI的一个子集,它不仅唯一标识资源,而且还提供了定位该资源的信息。URI是一种语义上的抽象概念,可以是绝对的,也可以是相对的,而URL则必须提供足够的信息来定位,是绝对的。

只要能唯一标识资源的就是URI,在URI的基础上给出其资源的访问方式的就是URL

生活例子:

  • 对于张三,可以用身份证号:123456789来唯一标识,所以身份证号就是URI
  • 但也可以用以下字符串标识张三:
    • 人类住址协议://地球/中国/浙江省/杭州市/西湖区/某大学/14号宿舍楼/525号寝/张三
    • 上面的字符串就是URL,同样起到了URI的作用,而且还可以通过上面的字符串找到张三的位置
  • 所以不论是用定位的方式还是用编号的方式,我们都可以唯一确定一个人,都是URl的一种实现,而URL就是用定位的方式实现的URI。

18.HTTP状态码

状态代码有三位数字组成,第一个数字定义了响应的类别,共分五种类别:

1xx:指示信息–表示请求已接收,继续处理

2xx:成功–表示请求已被成功接收、理解、接受

3xx:重定向–要完成请求必须进行更进一步的操作

4xx:客户端错误–请求有语法错误或请求无法实现

5xx:服务器端错误–服务器未能实现合法的请求

常见状态码:

  • 200 OK //客户端请求成功
  • 400 Bad Request //客户端请求有语法错误,不能被服务器所理解
  • 401 Unauthorized //请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用
  • 403 Forbidden //服务器收到请求,但是拒绝提供服务
  • 404 Not Found //请求资源不存在,eg:输入了错误的URL
  • 500 Internal Server Error //服务器发生不可预期的错误
  • 503 Server Unavailable //服务器当前不能处理客户端的请求,一段时间后可能恢复正常

更多状态码:http://www.runoob.com/http/http-status-codes.html

19.UDP打洞机制

原因:
路由器的NAT(网络地址转换)机制决定了内网访问外网容易,而外网访问内网困难,且不会接收来路不明的数据包

过程:
主要用于不同局域网的两台主机进行UDP通信,需要借助一个中间服务器。

例:局域网A中的主机A要和局域网B中的主机B进行通信,中间服务器为C:

  1. 两台局域网主机A和B分别先和服务器C连接,服务器C获得两边的经过NAT转换的ip和端口号。
  2. 其中一台局域网主机A,向服务器C发送消息,告诉服务器C他要和另一台局域网主机B进行打洞,服务器C接收到消息会把A经过NAT转换的ip和端口号发给B。
  3. B收到之后先给A的ip和端口发送一个消息,但是A不会收到消息,消息会被NAT丢弃,因为A不曾给B发送过消息,NAT没有注册这条通道,所以不认识B的ip和端口。然后主机B再给服务器发送个消息,让服务器告诉主机A这边已经注册好了NAT,可以进行通信。
  4. 主机A这时候拿到了服务器发给它的主机B经过NAT转换的ip和端口号,然后发送消息,主机B就可以进行接收了。两边就建立了一个类似洞口一样的东西,这就是UDP打洞。

打洞的目的是为了告诉NAT,我要访问的IP是我”朋友”,你不能阻拦它发过来的信息。

20.NAT实现方式

1. 全锥NAT(Full Cone NAT)

  • 这种NAT内部的机器A连接过外网机器C后,NAT会打开一个端口.然后外网的任何发到这个打开的端口的UDP数据报都可以到达A.不管是不是C发过来的.
  • 例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88
  • A(192.168.8.100:5000) -> NAT(202.100.100.100 : 8000) -> C(292.88.88.88:2000)
  • 任何发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)

2. 限制性锥NAT(Address-Restricted Cone NAT)

  • 这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口.然后C可以用任何端口和A通信.其他的外网机器不行.
  • 例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88
  • A(192.168.8.100:5000) -> NAT(202.100.100.100 : 8000) -> C(292.88.88.88:2000)
  • 任何从C发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)

3. 端口限制性锥NAT(Port Restricted Cone NAT)

  • 这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口.然后C可以用原来的端口和A通信.其他的外网机器不行.
  • 例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88
  • A(192.168.8.100:5000) -> NAT(202.100.100.100 : 8000) -> C(292.88.88.88:2000)
  • C(202.88.88.88:2000)发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)

4. 对称NAT(Symmetric NAT)

  • 在Symmetric NAT中,目标ip和端口则成为了NAT设备建立转换关系的一个重要考量:只有来自于同一个内部ip和端口、且针对同一目标ip和端口的请求才被NAT转换至同一个外部ip和端口,否则的话,NAT将为之分配一个新的外部ip和端口;
  • 打个比方,当内部主机以相同的内部ip和端口对2个不同的目标ip和端口发送UDP报文时,此时NAT将会为内部主机分配两个不同的外部ip和端口,并且建立起两个不同的内、外部 ip和端口转换关系。
  • 与此同时,只有接收到了内部主机所发送的数据包的外部主机才能向内部主机返回UDP报文,这里对外部返回报文来源的限制是与Port Restricted Cone一致的。

21.Nagle算法

问题描述

如果我们的应用程序一次产生1个字节的数据,而这个1个字节数据又以网络数据包的形式发送到远端服务器,那么就很容易导致网络由于太多的数据包而过载。比如,当用户使用Telnet连接到远程服务器时,每一次击键操作就会产生1个字节数据,进而发送出去一个数据包,所以,在典型情况下,传送一个只拥有1个字节有效数据的数据包,却要花费40个字节长包头(即ip头20字节+tcp头20字节)的额外开销,而且这种小包在广域网上会增加拥塞的出现,这种有效载荷(payload)利用率极其低下的情况被统称之为模糊窗口症候群(Silly Window Syndrome)

Nagle算法的改进

如果发送端欲多次发送包含少量字符的数据包(小于MSS的数据包为小包),则发送端会先将第一个小包发送出去,而将后面到达的少量字符数据都缓存起来而不立即发送,直到收到接收端对前一个数据包报文段的ACK确认、或当前字符属于紧急数据,或者积攒到了一定数量的数据(比如缓存的字符数据已经达到数据包报文段的最大长度)等多种情况才将其组成一个较大的数据包发送出去

Nagle算法的基本定义是任意时刻,最多只能有一个未被确认的小段。 所谓“小段”,指的是小于MSS尺寸的数据块,所谓“未被确认”,是指一个数据块发送出去后,没有收到对方发送的ACK确认该数据已收到。

MSS和MTU的区别

MTU 最大传输单元 maximum transmission unit

物理接口(数据链路层)提供给其上层(通常是IP层)最大一次传输数据的大小;以普遍使用的以太网接口为例,缺省MTU=1500 Byte,这是以太网接口对IP层的约束,如果IP层有<=1500 byte 需要发送,只需要一个IP包就可以完成发送任务;如果IP层有> 1500 byte 数据需要发送,需要分片才能完成发送,这些分片有一个共同点,即IP Header ID相同。

MSS 最大报文段长度 maximum segment size

TCP提交给IP层最大数据长度,不包含TCP Header和 TCP Option,只包含TCP 有效数据 ,MSS是TCP用来限制应用层最大的发送字节数。如果底层物理接口MTU= 1500 byte,则 MSS = 1500- 20(IP Header) -20 (TCP Header) = 1460 byte,如果应用层有2000 byte发送,需要两个报文段才可以完成发送,第一个TCP segment = 1460,第二个TCP segment = 540。

22.各层协议单元

物理层的协议数据单元 – 比特(bit)

数据链路层的协议数据单元 – 帧

网络层协议数据单元 – IP数据报(或简称为数据报、分组或包)

运输层的协议数据单元 – TCP的报文段或UDP的用户数据报

应用层的协议数据单元 – 报文

23.ICMP(网际控制报文协议)

ICMP差错报告报文

  1. 终点不可达: 当路由器或主机不能交付数据报时就向源点发送终点不可达报文
  2. 时间超过: 当路由器收到生存时间(TTL)为零的数据报时,除丢弃该数据报外,还有向源点发送时间超过报文。当终点在预先规定的时间内不能收到一个数据报的全部数据报片时,就把已收到的数据报片都丢弃,并向源点发送时间超过报文。
  3. 参数问题: 当路由器或目的主机收到的数据报的首部中有的字段的值不正确时,就丢弃该数据报,并向源点发送参数问题报文。
  4. 改变路由(重定向): 路由器把改变路由报文发送给主机,让主机知道下次应将数据报发送给另外的路由器(可通过更好的路由)

ICMP询问报文

  1. 回送请求和回答: ICMP回送请求报文是由主机或路由器向一个特定的目的主机发出的询问。收到此报文的主机必须给源主机或路由器发送ICMP回送回答报文,这种询问报文用来测试目的站是否可达以及了解其有关状态。
  2. 时间戳请求或回答: ICMP时间戳请求报文是请某台主机或路由器回答当前的日期或时间。时间戳请求与回答报文可用于时钟同步和时间测量。

ICMP应用举例

  1. PING,用来测试两台主机之间的连通性。PING使用了ICMP回送请求与回送回答报文。PING是应用层直接使用ICMP的一个例子。它没有经过运输层的TCP或UDP。
  2. UNIX系统的traceroute,它用来跟踪一个分组从源点到终点的路径。使用的是ICMP时间超过差错报告报文

24.负载均衡

定义

把负载压力根据某种算法合理分配到集群中的每一台计算机上,以减轻主服务器的压力,降低对主服务器的硬件和软件要求。

方式

HTTP重定向负载均衡

当用户发来请求的时候,Web服务器通过修改HTTP响应头中的Location标记来返回一个新的url,然后浏览器再继续请求这个新url,实际上就是页面重定向。通过重定向,来达到“负载均衡”的目标。

DNS域名解析负载均衡

DNS(Domain Name System)负责域名解析的服务,域名url实际上是服务器的别名,实际映射是一个IP地址,解析过程,就是DNS完成域名到IP的映射。而一个域名是可以配置成对应多个IP的。因此,DNS也就可以作为负载均衡服务。

反向代理负载均衡

反向代理服务可以缓存资源以改善网站性能。实际上,在部署位置上,反向代理服务器处于Web服务器前面(这样才可能缓存Web相应,加速访问),这个位置也正好是负载均衡服务器的位置,所以大多数反向代理服务器同时提供负载均衡的功能,管理一组Web服务器,将请求根据负载均衡算法转发到不同的Web服务器上。

负载均衡策略

  • 轮询
  • 加权轮询
  • 最少连接数
  • 最快响应
  • Hash法

25.子网掩码的作用?

子网掩码只有一个作用,就是将某个IP地址划分成网络地址和主机地址两部分

子网掩码是一个32位地址,用于屏蔽IP地址的一部分以区别网络标识和主机标识,并说明该IP地址是在局域网上,还是在广域网上。只有网络标识相同的两台主机在无路由的情况下才能相互通信。

子网掩码是一个32位的2进制数, 其对应网络地址的所有位都置为1,对应于主机地址的所有位都置为0。子网掩码告知路由器,地址的哪一部分是网络地址,哪一部分是主机地址,使路由器正确判断任意IP地址是否是本网段的,从而正确地进行路由。

工作过程

子网掩码工作过程是:将32位的子网掩码与IP地址进行二进制形式的按位逻辑“与” 运算得到的便是网络地址,将子网掩码二进制按位取反,然后IP地址进行二进制的逻辑“与”(AND)运算,得到的就是主机地址。如:192.168.10.10 AND 255.255.255.0,结果为192.168.10.0,其表达的含义为:该IP地址属于 192.168.10.0这个网络,其主机号为10,即这个网络中编号为10的主机。

子网划分

IP地址分网络号和主机号,要将一个网络划分为多个子网,因此网络号将要占用原来的主机位,如对于一个C类地址,它用24位来标识网络号,要将其划分为2个子网则需要占用1位原来的主机标识位。此时网络号位变为25位,主机标示变为7位。同理借用2个主机位则可以将一个C类网络划分为4个子网……那计算机是怎样才知道这一网络是否划分了子网呢?这就可以从子网掩码中看出。子网掩码和IP地址一样有32bit,确定子网掩码的方法是其与IP地址中标识网络号的所有对应位都用”1”,而与主机号对应的位都是”0”。如分为2个子网的C类IP地址用25位来标识网络号,则其子网掩码为:11111111 11111111 11111111 10000000即255.255.255.128。

—————————————-如有错误,欢迎指正!—————————————-

评论