网络编程、web服务器、TCP连接
- 01搭建一个服务器需要做哪些工作?(socket api调用过程)
- 02长链接和短链接适用于哪些场景
- 03服务端出现异常如何告诉所有客户端
- 04websocket
- 08项目中很麻烦,很难解决的问题
- 09项目最有价值的地方
- 10HTTP访问流程
- 09HTTPs建立连接的过程
- 09web服务器项目介绍
- 09timewait(最大报文段生存时间)状态原因
- 09closewait状态原因
- 09出现大量CLOSE_WAIT的原因及解决办法:
- 09客户端close了服务端发送数据会发生什么
- 10读URL的过程
- 11HTTPS的加密原理,对称/非对称加密的优缺点,为什么要混合使用
- 12TCP怎么实现可靠性,什么是拥塞控制
- 13http报文头都有哪些字段
01搭建一个服务器需要做哪些工作?(socket api调用过程)
//成功,将返回新套接字的文件描述符
int socket(int domain, int type, int protocol);
//绑定IP地址和端口号到 socketfd
int bind(int sockfd, const struct sockaddr *addr,socklen_t addrlen);
//监听
int listen(int sockfd, int backlog);
//连接,返回一个通信的套接字描述符
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
02长链接和短链接适用于哪些场景
HTTP短连接:在 HTTP/1.0 中默认使用短连接。也就是说,客户端和服务器每进行一次 HTTP 操作,就建立一次连接,任务结束就中断连接。 WEB 网站的 http 服务一般都用短链接,因为长连接对于服务端来说会耗费一定的 资源,而像 WEB 网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源。
HTTP长连接:从 HTTP/1.1 起,默认使用长连接,用以保持连接特性。在响应头加入这行代码:Connection:keep-alive。长连接多用于操作频繁,点对点的通讯,而且连接数不能太多情况。
03服务端出现异常如何告诉所有客户端
04websocket
WebSocket有以下特点:
是真正的全双工方式,建立连接后客户端与服务器端是完全平等的,可以互相主动请求。而HTTP长连接基于HTTP,是传统的客户端对服务器发起请求的模式。
HTTP长连接中,每次数据交换除了真正的数据部分外,服务器和客户端还要大量交换HTTP header,信息交换效率很低。Websocket协议通过第一个request建立了TCP连接之后,之后交换的数据都不需要发送 HTTP header就能交换数据,这显然和原有的HTTP协议有区别所以它需要对服务器和客户端都进行升级才能实现(主流浏览器都已支持HTML5)
08项目中很麻烦,很难解决的问题
09项目最有价值的地方
1、使用了类对server和client的处理程序进行了封装,提高了代码复用效率。
2、使用select进行io多路复用,防止线程阻塞。
3、在服务端中使用多线程的方式对客户端请求进行处理。
4、为了解决TCP粘包问题对数据进行一定了预处理。
10HTTP访问流程
1、使用DNS域名解析;
2、发起TCP的3次握手
3、建立TCP连接后发起http请求;
4、服务器响应http请求,浏览器得到返回response;
5、浏览器解析response,并请求其它的资源(如js、css、图片等);
6、浏览器对页面进行渲染。
09HTTPs建立连接的过程
1、客户端发起https连接,DNS域名解析获取IP地址,绑定443号端口,发送请求,并携带自己支持的加密算法带给服务端;
2、 服务端发送证书。服务端收到这套加密算法的时候,和自己支持的加密算法进行对比(也就是和自己的私钥进行对比),如果不符合,就断开连接;如果符合,服务端就将SSL证书发送给客户端,此证书中包括了数字证书包含的内容:1、证书颁发机构;2、使用机构;3、公钥;4、有效期;5、签名算法;6、指纹算法;7、指纹。
3、客户端验证服务端发来的证书
验证证书;生成随机数;生成握手信息
4、服务端接收随机数加密的信息,并解密得到随机数,验证握手信息是否被篡改。
5、客户端验证服务端发送回来的握手信息,完成握手
09web服务器项目介绍
09timewait(最大报文段生存时间)状态原因
一方面是为了等待这个客户重新连接的时候可以进行复用,另一方面必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
09closewait状态原因
在被动关闭连接情况下,在已经接收到FIN,但是还没有发送自己的FIN的时刻,连接处于CLOSE_WAIT状态。
09出现大量CLOSE_WAIT的原因及解决办法:
某种情况下对方关闭了socket链接,但是我方忙与读或者写,没有关闭连接
如果将大量CLOSE_WAIT的解决办法总结为一句话那就是:查代码。因为问题出在程序里头啊
判断read,一旦读到0,断开连接,
read返回负,检查一下errno,如果不是AGAIN,就断开连接。
09客户端close了服务端发送数据会发生什么
如果客户端主动关闭连接,客户端close了,客户端只是不能向服务端发送数据,但是可以接受数据,这就是TCP的半关闭。此时客户端处于FIN_WAIT2。
如果是服务端主动发起关闭,此时客户端再向服务端发送数据时,根据TCP协议的规定,认为它是一个异常终止连接,客户端将会收到一个RST复位响应(而不是ACK响应),如果客户端再次向服务端发送数据,系统将会发送一个SIGPIPE信号给客户端进程,告诉客户端进程该连接已关闭,不要再写了。系统给SIGPIPE信号的默认处理是直接终止收到该信号的进程,所以此时客户端进程会被极不情愿地终止。当服务端主动关闭,客户端继续写两次将会导致客户端进程被终止(服务端并不能接收),客户端不能向服务器写入数据。
10读URL的过程
客户端获取URL - > DNS解析 - > TCP连接 - >发送HTTP请求 - >服务器处理请求 - >返回报文 - >浏览器解析渲染页面 - > TCP断开连接
11HTTPS的加密原理,对称/非对称加密的优缺点,为什么要混合使用
https的大致工作流程如下:
1.客户端发起https请求。
2.服务端把申请好的公钥证书返回给客户端。
3.客户端通过上面的“数字证书验证流程”验证证书的合法性,如果通过则继续第4步,不通过则显示警告信息。
4.客户端生成一个“对称加密”所使用的密钥,然后用证书中的服务器公钥加密这个密钥,发送给服务端
5.服务端用自己的私钥解密,得到**“对称加密”密钥**。
6.服务端用得到的“对称加密”密钥加密一段明文,发送给客户端。客户端使用对称密钥解密得到的明文
7.客户端发起请求,使用对称密钥加密一段明文,服务端收到后用对称密钥进行解密,得到明文。
12TCP怎么实现可靠性,什么是拥塞控制
TCP的可靠性
1.为了保证数据包的可靠性,发送方必须把已发送的数据包保留在缓冲区;
2.并为每个已发送的数据包启动一个超时定时器;
3.如在定时器超时之前收到了对方发来的应答信息(可能是对本包的应答,也可以是对本包后续包的应答),则释放该数据包占用的缓冲区;
4.否则,重传该数据包,直到收到应答或重传次数超过规定的最大次数为止;
5.接收方收到数据包后,先进行CRC检验,如果正确则把数据与交给上层协议,然后给发送方发送一个累计应答包,表明该数据已收到,如果接收方正好也有数据要发给发送方,应答包也可放在数据包中捎带过去。
TCP的拥塞控制采用了四种算法,即 慢开始 、 拥塞避免 、快重传 和 快恢复。
慢启动:发送方成功接收接收方的确认,拥塞窗口cwnd就加倍。
拥塞避免:让cwnd缓慢的增加而不是加倍的增长,每经历过一次往返时间就使cwnd增加1
快重传:如果一连串收到3个或3个以上的重复ACK,就非常可能是一个报文段丢失了。于是我们就重传丢失的数据报文段,而无需等待超时定时器溢出。
快恢复:快速重传后执行的不是慢启动算法而是拥塞避免算法
13http报文头都有哪些字段
HTTP报文由报文首部 + 空行(CR+LF) +报文主体构成
get是从服务器上获取数据,post是向服务器传送数据。