在下方公众号后台回复:面试手册,可获取杰哥汇总的 3 份面试 PDF 手册。
请求报文格式:请求行、请求头、空一行、请求体
请求行包括:请求方法、统一资源定位符(URL)、http协议及版本
响应报文格式:状态行、响应头、空一行、响应体
状态行包括:协议及版本、状态码、状态码解释
http:由于http是明文传输,所以其安全性低,易受攻击,无法确认对方的身份,也无法确保数据的完整性;http协议默认端口号是80端口;它的优点是简单快速,使用很灵活;http服务器的程序规模小所以通信速度很快;与https相比,http没有额外的费用。
https:由于https使用ssh加密传输协议,信息是密文,所以它的安全性高,可以认证双方的身份,防止信息被截取篡改;https协议默认端口号是443端口;它会加重服务器负担,需要资源来支撑,降低用户的访问速度。
他们本质都是TCP连接,并无区别,但是由于http的规定以及浏览器和服务器的限制,导致他们在应用过程中可能有所不同
1、get方法的特点
2、post方法的特点
服务端新建套接字,绑定地址信息后开始监听,进入LISTEN状态。客户端新建套接字绑定地址信息后调用connect,发送连接请求SYN,并进入SYN_SENT状态,等待服务器的确认。服务端一旦监听到连接请求,就会将连接放入内核等待队列中,并向客户端发送SYN和确认报文段ACK,进入SYN_RECD状态。客户端收到SYN+ACK报文后向服务端发送确认报文段ACK,并进入ESTABLISHED状态,开始读写数据。服务端一旦收到客户端的确认报文,就进入ESTABLISHED状态,就可以进行读写数据了
两次不安全,四次没必要
tcp通信需要确保双方都具有数据收发的能力,得到ACK响应则认为对方具有数据收发的能力,因此双方都要发送SYN确保对方具有通信的能力。第一次握手是客户端发送SYN,服务端接收,服务端得出客户端的发送能力和服务端的接收能力都正常;第二次握手是服务端发送SYN+ACK,客户端接收,客户端得出客户端发送接收能力正常,服务端发送接收能力也都正常,但是此时服务器并不能确认客户端的接收能力是否正常;第三次握手客户端发送ACK,服务器接收,服务端才能得出客户端发送接收能力正常,服务端自己发送接收能力也都正常。
客户端主动调用close时,向服务端发送结束报文段FIN报,同时进入FIN_WAIT1状态;服务器会收到结束报文段FIN报,服务器返回确认报文段ACK并进入CLOSE_WAIT状态,此时如果服务端有数据要发送的话,客户端依然需要接收。客户端收到服务器对结束报文段的确认,就会进入到FIN_WAIT2状态,开始等待服务器的结束报文段;服务器端数据发送完毕后,当服务器真正调用close关闭连接时,会向客户端发送结束报文段FIN包,此时服务器进入LAST_ACK状态,等待最后一个ACK的带来;客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出送确认报文段ACK;服务器收到了对结束报文段确认的ACK,进入CLOSED状态,断开连接。而客户端要等待2MSL的时间,才会进入到CLOSED状态
第二步属于系统自动响应数据包
第三步是程序手动调用close()方法发送关闭连接的请求数据包
其实在TCP握手的时候,接收端将SYN包和ACK确认包合并到一个包中发送的,所以减少了一次包的发送。对于四次挥手,由于TCP是全双工通信,主动关闭方发送FIN请求不代表完全断开连接,只能表示主动关闭方不再发送数据了。而接收方可能还要发送数据,就不能立即关闭服务器端到客户端的数据通道,所以就不能将服务端的FIN包和对客户端的ACK包合并发送,只能先确认ACK,等服务器无需发送数据时在发送FIN包,所以四次挥手时需要四次数据包的交互
TIME_WAIT是主动关闭方出现的,一台主机出现大量的TIME_WAIT证明这台主机上发起大量的主动关闭连接。常见于一些爬虫服务器。这时候我们应该调整TIME_WAIT的等待时间,或者开启套接字地址重用选项
CLOSE_WAIT是被动关闭方收到FIN请求进行回复之后的状态,等待上层程序进一步处理,若出现大量CLOSE_WAIT,有可能是被动关闭方主机程序中忘了最后一步断开连接后调用close释放资源。这是一个 BUG,只需要加上对应的 close 即可解决问题
可靠性和提高性能可参考此链接!!!
确认应答、超时重传、连接管理、流量控制、拥塞控制
滑动窗口、延迟应答、捎带应答
TCP是可靠,稳定的,TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认应答、超时重传、连接管理、流量管理、拥塞控制机制,在数据传完后,还会四次挥手断开连接用来节约系统资源。但是它相对UDP较慢,效率低,占用系统资源高,而且在数据传递时,确认机制、重传机制、拥塞控制机制等都会消耗大量的时间,而且要在每台设备上维护所有的传输连接,每个连接都会占用系统的CPU、内存等硬件资源。
UDP没有TCP的确认应答、超时重传、连接管理、流量管理、拥塞控制等机制,是一个无状态的传输协议,所以它在传递数据时非常快。但是UDP不可靠、不稳定,因为UDP没有TCP那些可靠的机制,在数据传递时,如果网络质量不好,就会很容易丢包。
总的来说
TCP是面向连接的,UDP无连接 TCP是可靠的,UDP不可靠 TCP只支持对点的通信;UDP支持一对一,一对多,多对一,多对多通信 TCP是面向字节流的;UDP是面向数据报的 TCP首部开销大,20个字节;UDP只有8个字节 TCP可以保证传输的顺序,UDP不可以保证
浏览器缓存:浏览器会记录DNS一段时间,因此只有第一个地方解析DNS请求 操作系统缓存:如果在浏览器中不包含这个记录,则会使用系统调用操作系统,获取操作系统记录(保存最近的DNS查询缓存) 路由器缓存:如果上述两个步骤均不能获取DNS记录,继续搜索路由器缓存
(1)排除接触故障
查看网线是否连接正常。如果网络连接图标上显示“红叉”,则说明网络连接不正常。可检查主机网卡口上的网线、交换器(路由器)上网线是否正常连接
(2)使用ipconfig查看计算机的上网参数
①单击“开始|所有程序|附件|命令提示符“,打开命令提示符窗口
②输入ipconfig,按Enter确认,可以看到机器的配置信息,输入ipconfig/all,可以看到IP地址和网卡物理地址等相关网络详细信息。
(3)使用ping命令测试网络的连通性
在命令提示符窗口中输入"ping 127.0.0.1",数据显示本机分别发送和接受了4个数据包,丢包率为零,可以判断本机网络协议工作正常,如显示”请求超时“,则表明本机网卡的安装或TCP/IP协议有问题,接下来就应该检查网卡和TCP/IP协议,可以通过重新安装该协议来解决。安装方法:右击“本地连接”——属性——安装——协议,选择TCP/IP协议确定安装。
(4)ping本机IP
如果ping 127.0.0.1 正常,则可以“ping 本机IP”来判断本机的网卡是否正常工作。如不能ping通,说明本机的网卡驱动程序不正确,或者网卡与网线之间连接有故障,也有可能是本地的路由表面收到了破坏,此时应检查本机网卡的状态是否为已连接,网络参数是否设置正确,如果正确可是不能ping通,就应该重新安装网卡驱动程序。丢失率为零,可以判断网卡安装配置没有问题,工作正常。
(5)ping网关IP
网关地址能被ping通的话,表明本机网络连接已经正常,如果命令不成功,可能是网关设备自身存在问题,也可能是本机上网参数设置有误,检查网络参数。如果ping 网关IP正常,可网页却无法打开,同时QQ可以正确登录。则一般是DNS填写不正确,请联系运行商询问DNS地址,也可询问邻居他们是怎么设置的,一个地区的同一运行商所用的DNS都是一样的。