【成神之路】Http 络相关面试题

OSI七层模型分别对应着五层模型的哪一部分；

OSI七层模型，每层都说下自己的理解和知道的，说的越多越好；

络模型的分层、IP和Mac地址在那个层、TCP和HTTP分别在那个层；

应用层：HTTP、FTP、TELNET等

传输层：UDP,TCP

络层：IP（32位），ICMP

数据链路层：ARP,RARP,MAC（48位）

从游览器中输入URL到页面加载的发生了什么参考《从输入URL到页面加载发生了什么》

https://blog.csdn.net/w372426096/article/details/82012229

浏览器输入https:www.koolearn.com这个URL，浏览器只知道名字是www.koolearn.com,但不知道具体的放完地址，名称只是方便记；首先使用“地址薄”协议DNS或精准的HTTPDNS查找，最终会找到IP地址，也就是互联 世界里的门牌 。知道地址，浏览器开始打包请求，使用Http协议或者加密传输Https协议。DNS，HTTP，HTTPS所在层都是应用层，通过socket变成传输下一层传输层。

传输层有TCP和UDP两种连接协议，传输层封装后，浏览器会将包交给操作系统的 络层。
络层协议是IP协议（包含浏览器所在机器的 IP 地址和目标 IP 地址），操作系统知道目标IP地址，就可以找到目标机器；目标又分国内国外，国外通过 关；本地地址是mac地址。

操作系统将 IP 包交给了下一层，也就是MAC 层。 卡再将包发出，因为有mac地址所以能够到达 关。 关收到包后，会根据自己的判断能力进行下一步， 关往往是一个路由器，一层一关知道找到目标服务器

扩展：

当 络包到达一个城关的时候，可以通过路由表得到下一个城关的IP 地址，直接通过 IP 地址找就可以了，为什么还要通过

本地的 MAC 地址呢/p>

1.局域 内IP地址是动态分配的，假如我是192.168.2.100，如果我下线了，可能IP就分配给了另一台电脑。IP和设备并不总是对应的，这对通信就产生了问题，但是MAC地址不同，MAC地址和设备是一一对应且全球唯一的。所以局域 使用MAC地址通信没有问题。2.历史遗留问题：早期的以太 只有交换机，没有路由器，以太 内通过MAC地址通信。后来才有了互联 ，为了兼容原本的模式，采用了IP+MAC地址通信的方式。为啥不推到了重来呢看IPv6的处境你就知道了。所以是先有MAC地址后有的IP，IP的提出主要还是因为MAC地址本身的缺陷，这个问题换成有了MAC为何还要IP地址也很有意思。3.我这里简单说一下第一：MAC地址本身的缺陷：因为MAC地址是硬件提供商写在 卡中的，MAC地址虽然唯一但是不能表明用户在整个互联 中的位置，除非维护一个超级大MAC地址对应表，那寻址效率肯定爆炸。但是IP地址解决了这个问题，因为IP地址是 络提供商给你的，所以你在哪里整个 络都是知道的。第二：安全问题：获取MAC地址是通过ARP协议来完成的，如果只用MAC地址通信，那么广播风暴是个难题。4.那么我觉得如果哪天每人一个固定的IPv6地址，那么我觉得MAC地址+IPv4的模式是不是可以被替换了/p>

数据链路层是做什么的/strong>

成帧，差错控制，流量控制，链路管理，MAC寻址，区分数据与控制信息，透明传输，

1、封装成帧

封装成帧就是在一段数据前后分别加入首部和尾部，构成了一个帧。

2、透明传输

解决透明传输的方法：

1、发送端的数据链路层在数据中出现控制字符“SOH”或“EOT”的前面插入一个转义字符“ESC”(其十六进制编码是 1B)。
2、字节填充或字符填充——接收端的数据链路层在将数据送往 络层之前删除插入的转义字符。
3、假设转义字符也出现数据其中。那么应在转义字符前面插入一个转义字符。当接收端收到连续的两个转义字符时。就删除其中前面的一个。

实现方法见下图：

3、差错检測

在传输过程中可能会产生比特差错：1 可能会变成 0 而 0 也可能变成 1。
为了保证数据传输的可靠性，在计算机 络数据传输时。必须採用各种差错检測措施。 

数据链路层的流量控制/strong>

滑动窗口

https://blog.csdn.net/jeffleo/article/details/53932693

http 默认端口，https 默认端口

HTTP协议代理服务器常用端口 ：80/8080/3128/8081/9098

HTTPS（securely transferring web pages）服务器，默认端口 为443/tcp  443/udp

TOMCAT，默认端口 为8080

Http的Http basic authentication;

https://www.cnblogs.com/yuqiangli0616/p/9389273.html

Http1.0和2.0相比有什么区别，可参考《Http 2.0》

https://blog.csdn.net/w372426096/article/details/81282071

什么是长连接和短连接

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个 页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
而像WEB 站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB 站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

http://blog.jobbole.com/104108/

Https的基本概念;Https和Http有什么区别；如果我篡改了公钥呢么防止/strong>

HTTPS (基于安全套接字层的超文本传输协议 或者是 HTTP over SSL) 是一个 Netscape 开发的 Web 协议。

可以说：HTTPS = HTTP + SSL；HTTPS 在 HTTP 应用层的基础上使用安全套接字层作为子层。

为什么需要 HTTPS /p>

超文本传输协议 (HTTP) 是一个用来通过互联 传输和接收信息的协议。HTTP 使用请求/响应的过程，因此信息可在服务器间快速、轻松而且精确的进行传输。当你访问 Web 页面的时候你就是在使用 HTTP 协议，但 HTTP 是不安全的，可以轻松窃听你跟 Web 服务器之间的数据传输。在很多情况下，客户和服务器之间传输的是敏感信息，需要防止未经授权的访问。为了满足这个要求， 景公司(Netscape)推出了 HTTPS，也就是基于安全套接字层的 HTTP 协议。

HTTP 和 HTTPS 的相同点

大多数情况下，HTTP 和 HTTPS 是相同的，因为都是采用同一个基础的协议，作为 HTTP 或 HTTPS 客户端——浏览器，设立一个连接到 Web 服务器指定的端口。当服务器接收到请求，它会返回一个状态码以及消息，这个回应可能是请求信息或者指示某个错误发送的错误信息。系统使用统一资源定位器 URI 模式，因此资源可以被唯一指定。而 HTTPS 和 HTTP 唯一不同的只是一个协议头(https)的说明，其他都是一样的。

HTTP 和 HTTPS 的不同之处

1. HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
2. HTTP 是不安全的，而 HTTPS 是安全的
3. HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
4. 在 OSI 络模型中，HTTP 工作于应用层，而 HTTPS 工作在传输层
5. HTTP 无需加密，而 HTTPS 对传输的数据进行加密
6. HTTP 无需证书，而 HTTPS 需要认证证书

HTTPS 如何工作/p>

使用 HTTPS 连接时，服务器要求有公钥和签名的证书。

当使用 https 连接，服务器响应初始连接，并提供它所支持的加密方法。作为回应，客户端选择一个连接方法，并且客户端和服务器端交换证书验证彼此身份。完成之后，在确保使用相同密钥的情况下传输加密信息，然后关闭连接。为了提供 https 连接支持，服务器必须有一个公钥证书，该证书包含经过证书机构认证的密钥信息，大部分证书都是通过第三方机构授权的，以保证证书是安全的。

换句话说，HTTPS 跟 HTTP 一样，只不过增加了 SSL。

HTTP 包含如下动作：

1. 浏览器打开一个 TCP 连接
2. 浏览器发送 HTTP 请求到服务器端
3. 服务器发送 HTTP 回应信息到浏览器
4. TCP 连接关闭

SSL 包含如下动作：

1. 验证服务器端
2. 允许客户端和服务器端选择加密算法和密码，确保双方都支持
3. 验证客户端(可选)
4. 使用公钥加密技术来生成共享加密数据
5. 创建一个加密的 SSL 连接
6. 基于该 SSL 连接传递 HTTP 请求

HTTPS 协议的总体思路：

什么时候该使用 HTTPS/p>

银行 站、支付 关、购物 站、登录页、电子邮件以及一些企业部门的 站应该使用 HTTPS，例如：

Http 为什么是无状态的；

一.无连接

1. 每一个访问都是无连接，服务器挨个处理访问队列里的访问，处理完一个就关闭连接，这事儿就完了，然后处理下一个新的
2. 无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接

二.无状态

     1.协议对于事务处理没有记忆能力

     2.对同一个url请求没有上下文关系

     3.每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况

     4.服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器

    关于无状态的理解 和 误解 （http://www.cnblogs.com/bellkosmos/p/5237146.html）

TCP为什么可靠；三次握手和四次挥手、为什么挥手需要四次

https://blog.csdn.net/w372426096/article/details/81836919

TCP三次握手数据丢失了怎么办如果后面又找到了呢/strong>

Server 端

    第三次的ACK在 络中丢失，那么Server 端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。

    而Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5.

    如果重发指定次数之后，仍然未收到 client 的ACK应答，那么一段时间后，Server自动关闭这个连接。

Client 端

    在linux c 中，client 一般是通过 connect() 函数来连接服务器的，而connect()是在 TCP的三次握手的第二次握手完成后就成功返回值。也就是说 client 在接收到 SYN+ACK包，它的TCP连接状态就为 established （已连接），表示该连接已经建立。那么如果 第三次握手中的ACK包丢失的情况下，Client 向 server端发送数据，Server端将以 RST包响应，方能感知到Server的错误。

TCP的同步传输，拆包与组装包是什么意思；

https://www.cnblogs.com/wade-luffy/p/6165671.html

TCP的拥塞控制、流量控制详细说明/strong>

https://blog.csdn.net/qq_38623623/article/details/81290265

https://blog.csdn.net/dangzhangjing97/article/details/81008836

两个不同ip地址的计算机之间如何通信；

https://blog.csdn.net/qulang000/article/details/60335093

ping使用了什么协议，用了哪几层 络结构/strong>

icmp,控制 文协议，IP，mac层 络层

icmp为什么可以实现ping的

侦查兵轻装上阵，发送的udp,又返回码值

地址解析协议ARP；

https://www.cnblogs.com/csguo/p/7542944.html

知道哪些使用UDP协议的成功案例；

DNS在进行区域传输的时候使用TCP协议，其它时候（域名解析）则使用UDP协议；

实时语音，视频等

单个UDP 文最大容量；

结论1：局域 环境下，建议将UDP数据控制在1472字节以下
以太 (Ethernet)数据帧的长度必须在46-1500字节之间,这是由以太 的物理特性决定的，这个1500字节被称为链路层的MTU(最大传输单元)。但这并不是指链路层的长度被限制在1500字节，其实这这个MTU指的是链路层的数据区，并不包括链路层的首部和尾部的18个字节。

所以，事实上这个1500字节就是 络层IP数据 的长度限制。因为IP数据 的首部为20字节，所以IP数据 的数据区长度最大为1480字节。而这个1480字节就是用来放TCP传来的TCP 文段或UDP传来的UDP数据 的。

又因为UDP数据 的首部8字节，所以UDP数据 的数据区最大长度为1472字节。这个1472字节就是我们可以使用的字节数。

当我们发送的UDP数据大于1472的时候会怎样呢/strong> 这也就是说IP数据 大于1500字节，大于MTU，这个时候发送方IP层就需要分片(fragmentation)。把数据 分成若干片，使每一片都小于MTU，而接收方IP层则需要进行数据 的重组。这样就会多做许多事情，而更严重的是，由于UDP的特性，当某一片数据传送中丢失时，接收方无法重组数据 ，将导致丢弃整个UDP数据 。
因此，在普通的局域 环境下，我建议将UDP的数据控制在1472字节以下为好。

结论2：Internet编程时，建议将UDP数据控制在548字节以下
进行Internet编程时则不同，因为Internet上的路由器可能会将MTU设为不同的值。如果我们假定MTU为1500来发送数据，而途经的某个 络的MTU值小于1500字节，那么系统将会使用一系列的机制来调整MTU值，使数据 能够顺利到达目的地，这样就会做许多不必要的操作。
鉴于Internet上的标准MTU值为576字节，所以我建议在进行Internet的UDP编程时， 最好将UDP的数据长度控件在548字节(576-8-20)以内。   

ps：这句话貌似有问题，unix 络编程第一卷里说：ipv4协议规定ip层的最小重组缓冲区大小为576！所以，建议udp包不要超过这个大小，而不是因为internet的标准MTU是576！

单个TCP 文最大容量；

MTU:最大传输单元,以太 的MTU为1500Bytes

MSS：最大分解大小，为每次TCP数据包每次传输的最大数据的分段大小，由发送端通知接收端,发送大于MTU就会被分片。

MSS默认最小为536B，最小的MTU576B,MSS = MTU – IP头（20B）- TCP头（20B）

TCP最小数据长度为1460Bytes

　　以太 的最大数据帧是1518Bytes

　　以太 的帧头148Bytes：MAC目的地址48bit（6B），MAC源地址48bit（6B），Type域2B，一共14B

　　帧尾校验4Bytes

　　数据域只剩：1518-14-4 = 1500Bytes

　　TCP数据包大小 1500 – IP头（20B）- TCP头（20B） = 1460B 这也是最大的MSS

　　（UDP数据包 1500 – IP头（20B） – UDP头（8B） = 1472B）

TCP最大负载65535-40B

　　TCP 文段的最大负载为65495字节，因为每个数据段必须适合IP的载荷能力，不能超过65535字节，IP头20B，TCP包头20B，

　　故最大负载为65535- 20-20=65495B

ack字段大小为84B

　　前导码 8 + 目的MAC 6 + 源MAC 6 + 类型 2 + IP首部 20 + TCP首部 20 + 用户数据 0 + 填充字符 6 + CRC 4 + 分组间隙 12 = 84B

TCP：64B

　　以太 帧首部　　14B：MAC目的地址48bit（6B），MAC源地址48bit（6B），Type域2B，一共14B

　　以太 帧尾部　　4B

　　IP　　20B

　　TCP　　20B　　（UDP　　8B）

　　填充　　6B　　  （UDP填充　　18B）

　　一共58B，不够64B ，填充6B。

TCP最小长度

　　是默认的MSS产生536B，还是ACK的长度84B，还是TCP总长（加IP，MAC）的64B

TCP 头格式、UDP 头格式；

https://www.cnblogs.com/Allen-rg/p/7190042.html

HTTP、TCP、UDP的区别和联系；

HttP是应用层协议，基于TCP的。

传输层有两个性质不同的协议：TCP（Transmission ControlProtocol，传输控制协议）和 UDP（User Data Protocol，?户数据 协
议）。

TCP与UDP区别总结：

1、TCP面向连接（如打电话要先拨 建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向 文的
UDP没有拥塞控制，因此 络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节

6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

UDP实现可靠传输：

由于在传输层UDP已经是不可靠的连接，那就要在应用层自己实现一些保障可靠传输的机制

简单来讲，要使用UDP来构建可靠的面向连接的数据传输，就要实现类似于TCP协议的

超时重传（定时器）

有序接受 （添加包序 ）

应答确认 （Seq/Ack应答机制）

滑动窗口流量控制等机制 （滑动窗口协议）

等于说要在传输层的上一层（或者直接在应用层）实现TCP协议的可靠数据传输机制，比如使用UDP数据包+序列 ，UDP数据包+时间戳等方法。

目前已经有一些实现UDP可靠传输的机制，比如UDT

TCP 实现可靠传输

通过三次握手连接，四次挥手断开的机制

Server遭遇SYN Flood应当怎么处理；

https://www.cnblogs.com/qiaoconglovelife/p/5713661.html

DHCP如何实现分配IP的；

发现阶段（DHCP客户端在 络中广播发送DHCP DISCOVER请求 文，发现DHCP服务器，请求IP地址租约）、提供阶段（DHCP服务器通过DHCP OFFER 文向DHCP客户端提供IP地址预分配）、选择阶段（DHCP客户端通过DHCP REQUEST 文确认选择第一个DHCP服务器为它提供IP地址自动分配服务）和确认阶段（被选择的DHCP服务器通过DHCP ACK 文把在DHCP OFFER 文中准备的IP地址租约给对应DHCP客户端）。

Get和Post，讲下区别，要我模拟出抓包来。

GET	POST
后退按钮/刷新	无害	数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
书签	可收藏为书签	不可收藏为书签
缓存	能被缓存	不能缓存
编码类型	application/x-www-form-urlencoded	application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
历史	参数保留在浏览器历史中。	参数不会保存在浏览器历史中。
对数据长度的限制	是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。	无限制。
对数据类型的限制	只允许 ASCII 字符。	没有限制。也允许二进制数据。
安全性	与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。 在发送密码或其他敏感信息时绝不要使用 GET ！	POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性	数据在 URL 中对所有人都是可见的。	数据不会显示在 URL 中。

1. GET提交的数据会放在URL之后，以割URL和传输数据，参数之间以&相连，如EditPosts.aspxame=test1&id=123456.POST方法是把提交的数据放在HTTP包的Body中.

2. GET方式需要使用Request.QueryString来取得变量的值，而POST方式通过Request.Form来获取变量的值。

详细讲下Cookie和Session，Token，OAuth2.0协议;

https://blog.csdn.net/w372426096/article/details/88314102

socket熟悉吗它的读写缓冲区有理解吗/strong>

https://donald-draper.iteye.com/blog/2356885

有比较过 Http 和 RPC 吗/strong>

1.rpc只是一种概念，实现rpc的方式有很多种，但本质上都需要客户端和服务端之间有一个通信协议，这个协议用于规范两个进程通过 络传输数据时数据的格式，一边按照协议把数据装配好通过 络传输，另一边按照协议把接收的二进制数据翻译成有用的数据，这个协议一定是两端商量好使用同一种的。也就是类似两个人交流，需要一个双方都懂的语言，一边说汉语一边说英语肯定是无法提供交流的，两边都说同一种话才能交流，一边通过语言的定义把他要表达的意图/想法转换成文字/发音提交给另一方，另一方通过语言的定义，在大脑中将文字翻译为真正要表达的东西。

2.并且协议是不可能没有的，比如就算你用Java的序列化方式来传输数据，那也是按Java序列化规范了数据格式，那也是一种两端都协定好的协议；亦或是你自己实现了某种传输的数据的格式，通信的两端都可以用你的规范下编写的编解码工具来处理/翻译数据，这也是一种协议。就好像原始人交流，通过呃呃啊啊几个简单音节配以手舞足蹈的动作，这种“语言”虽然简陋，但也实现了交流的目的，那他就是原始人的语言。

3.所以这个协议可以是soap协议，也可以是http协议，你不能说用http协议交流的远程过程调用就不算rpc了，用什么协议是服务端和客户端在开发时决定的，本质上是实现rpc，只是每个协议都有其自己的特性，不同的协议之间，会有一些比较大的区别，差异比较大的一个例子，比如说利用Json传输数据，翻译和构造都非常耗时，数据也很大，优点是开发人员友好，数据可读性强，调试方便，而使用Hession、protobuf，数据处理快，可读性差，优点就是快，但这个快体现在数据量小、处理快，和 络没有关系。

4.综上，RPC和HTTP根本不是一个层面的东西

最后，我看了上面的回答，有好几个问题不明白，有的人把http协议和tcp协议并列起来谈，这两个不是一个上一个下吗，没有tcp协议，哪来的http协议的说“自定义tcp协议”，是表达错误吗想说“基于tcp协议传输的自定义协议”吗的说HTTP开销在连接的建立与断开上，难道其他RPC协议不走TCP吗TTP也是可以实现长连接的吧，再不济，抛去第三方的实现，自己实现一个基于HTTP协议的通信工具，每次交互忽视HTTP头关于连接的部分，永远是长连接，只是把HTTP协议作为数据交流的协议不也OK吗。

良好的rpc调用是面向服务的封装，针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性。

https://www.jianshu.com/p/5b90a4e70783

HttpClient 你说说里面的具体实现吧/strong>

https://blog.csdn.net/w372426096/article/details/82713315

那要你设计一个高性能的 Http ，你会怎么设计/strong>

【高性能HTTP应用的策略】

所以，当我们需要一个高性能的HTTP接口型应用时：

1、服务器端：关闭KeepAlive。

2、服务器端：最好直接支持HTTP协议（注意用POST，不要GET）,而不是任何包装过的协议，比如：hessian/soap等。

3、服务器端：在一个请求中，最好设计成：支持多条指令批处理，以节省连接数。

4、服务器端：对请求的处理应当尽可能的快（如在150ms内）。

5、客户端：在代码中，同一个客户端实例中全部请求结束后应主动关闭连接（无须事先设置客户端的ConnectionTimeOut参数）。

6、客户端：如服务器未关闭KeepAlive，在同一个客户端实例中可以适量发出多个请求（总时间应稍小于服务器KeepAliveTimeout参数）。此方式需要精确操作，不推荐。

最后，在接口设计上，对于一些异步操作，尽量不要设计成单方面轮询模式（减少大量无谓请求数），应设计成被调用方的异步结果回调模式。

【一些优化细节】

在服务器端，我们一般选用的是Apache+Tomcat/JBoss的组合。关于JBoss的配置及优化可参看JBoss官 。

最主要的是关于Apache的优化，推荐阅读两篇文章：
1、Apache性能优化：http://www.aliwo.net:8080/2009/12/apache/

2、Apache中KeepAlive配置的合理使用：http://www.net527.cn/a/caozuoxitong/Linux/5283.html

在客户端的Java代码中，我们最常使用的是HttpClient工具包。

有一些细节要注意：

1、在每一个HttpClient实例发完请求后，（如不再使用）应及时关闭连接。

最简单的方式是，在HTTP Request Header中发送(Connection: close)，指示服务器关闭当前连接。

代码如下：

method.setRequestHeader(“Connection”, “close”);

2、可以设计为单例模式：无需每次创建HttpClient实例，可多次发送请求

参考：http://seanhe.iteye.com/blog/234759

DNS 你知道是干嘛的吗/strong>

DNS域名系统：解析域名，每个ip地址都可以有一个主机名，主机名由一个或多个字符串组成，字符串之间用小数点隔开。有了主机名，就不要死记硬背每台IP设备的IP地址，只要记住相对直观有意义的主机名就行了。这就是DNS协议的功能。

如何防范常见的Web攻击、如何方式SQL注入

https://blog.csdn.net/han_cui/article/details/61418484

服务端通信安全攻防

Web开发中如何防范XSS/strong>

什么是XSS攻击，XSS攻击的一般表现形式有哪些何防止XSS攻击；

文章知识点与官方知识档案匹配，可进一步学习相关知识 络技能树跨区域 络的通信学习 络层的作用22057 人正在系统学习中