目录
1.HTTP1.0和HTTP1.1区别
2.socket系列接口与TCP协议
3.传输长数据的时候考虑网络问题
4.慢查询如何优化
5.C++的垃圾回收机制
1.HTTP1.0和HTTP1.1区别
- 在连接方式上,HTTP1.0默认采用的是短链接的方式,就建立一次通信,也就是说即使在TCP协议下,完成了一个HTTP报文的请求和响应之后,也会关闭连接。这种频繁的建立和关闭连接会增加服务器的负担。虽然说HTTP1.0版本不支持长连接,但是可以通过设置Connection: Keep-Alive字段来启动类似长连接的功能,但是是不标准的方式。而HTTP1.1引入了长连接机制,在一个TCP连接上可以传递多个HTTP请求与响应报文。
- 缓存机制上,HTTP1.0采用的是通过字段的方式指定缓存的内容有效时间,客户端在这段时间内可以使用缓存的副本而无需向服务器重新请求。但是这样的话也无法验证数据的实时性,可能服务端更新了呢?而HTTP1.1版本的话,增加了缓存控制能力,提供了字段来规定客户端在使用缓存内容的时候,需要先向服务端验证数据的有效性。
2.socket系列接口与TCP协议
- socket建立网络通信套接字、bind进行ip地址和端口号绑定、服务端进行listen监听操作是在通信之间进行的。
- connect接口:操作客户端向服务器发起连接请求,在TCP协议层的操作就是相当于发起三次握手,直到客户端收到第二次握手的SYN+ACK响应报文,connect函数才会返回,期间会一直阻塞住。
- accept接口:服务端在接收到第三次握手的ACK报文之后,会和客户端真正的建立连接,之后accept就是将全连接队列中的连接对象与文件描述符建立连接。
- listen接口的第二个参数:就是全连接队列的最大长度。
3.传输长数据的时候考虑网络问题
当网络出现问题的时候导致的数据丢包的问题,并非是TCP协议能够解决的问题了,因为TCP协议是在网络通畅,双方连接没有断开的情况下,维护发送但没有收到应答的时候,但是一旦网络出问题了,就相当于连接断开了,那么在销毁这个连接的时候,TCP缓存的数据也就跟着销毁了。但是我们想做到的是,当网络出现问题之后,在重新建立连接,数据会从上一次断开连接的位置之后发送数据。
那么首先就需要在应用层协议的报头上加入类似于TCP协议的32位序号和确认序号了,但是这里一个负责发送一个负责响应,所以只用一个序号就可以了。服务端报文的序号代表发送的数据序号,客户端报文的序号代表接收到的数据块序号。
之后再服务端的应用层,维护一个指针指向整体数据的已经发送并且得到确认的位置,那么就分成了两个区域,指针左边就是已发送已确认区域,右边是没发送或者发送了没有确认的区域,这样的话,该指针指向的位置,就是客户端收到数据的位置。如果说网络出现问题的话,再重新连接之后,会根据客户端发来的序号,更新指针的位置,继续发送数据。
对于客户端来说,也需要再应用层将这些数据保存起来,并记录收到的最后一个数据的序号,在网络问题断开连接后,重新连接,会将该序号放进报头中,告诉服务端该从哪里发送了。
因为是分块发送的,所以服务端最后需要告诉客户端数据发送完毕了,所以就会出现很多类型报文,所以还需要再报头添加报文类型字段:客户端请求响应报文,服务端发送数据块报文、客户端接收到数据块的响应报文、服务端发送完所有数据的报文。
4.慢查询如何优化
慢查询是数据库的一个概念,指的是执行时间过长超过了long_query_time设定的值的擦汗寻语句,就属于慢查询语句。慢查询会对数据库的性能产生严重影响,当数据库中有大量的慢查询的时候,会导致数据库服务器的CPU使用了过高。还可能导致数据库连接池被沾满,新的请求无法及时获取到。
- 优化查询语句本身:第一:索引优化;第二:子查询优化,尽量减少嵌套查询的使用,例如,有一个查询需要获取购买了某一商品的用户信息,一种不好的做法是先通过子查询找到购买了该商品的用户 ID,然后再在另一个查询中根据这些用户 ID 获取用户信息。这种嵌套子查询可以通过使用连接(JOIN)操作来优化;第三:尽量不要使用select *语句。
- 优化数据库架构:第一:采用合理的数据类型定义字段;第二:对于大型数据表,可以考虑使用分区结构
- 优化服务器配置:第一:调整缓存大小,第二:硬件的升级
5.C++的垃圾回收机制
C++没有配套的垃圾回收机制,需要程序员使用new、delete去手动的管理内存资源,也可以使用C++11的智能指针,配合析构函数来实现对资源的自动管理。或者使用第三方库来实现资源的回收工作。