asp.net做织梦网站网站开发岗位
目录
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的智能指针，配合析构函数来实现对资源的自动管理。或者使用第三方库来实现资源的回收工作。