Remote communication protocol

First. Http request of a whole process

1.1 Overview

So in a distributed architecture, there is a very important aspect, is the need to communicate with each other computer nodes in a distributed network. Visiting various sites with a browser, as users only need to enter a URL and jump right

Turn on the line. But as a programmer, to see this response is probably behind the whole process.

1.2 DNS DNS service

First, the user access to a domain name, DNS resolution will go through DNS (Domain Name System), and it is located in the same HTTP protocol application layer protocol, primarily to provide domain name

IP resolution services. In fact, we do not have domain name can also access the target host service, but IP itself is not so easy to remember, so use a domain name replacement makes it easier for users to remember.

 

 1.3Http protocol Communication Theory

Http communication protocol is based on an application layer protocol over tcp / ip protocol, application layer protocols other http What does (FTP, DNS, SMTP, Telnet, etc.).

Relates to network protocols, OSI seven layer network model and the TCP / IP four-layer model concepts, OSI seven layer network model comprising (application layer, presentation layer, session layer, transport layer, network layer, data link layer, physical layer), TCP / IP four

Layer comprising a conceptual model (an application layer, transport layer, network layer, data link layer).

Request to initiate the process, doing things in tcp / ip four-layer network model

When an application using TCP to transfer data, the data is sent to the protocol stack, through each layer then one by one until it is fed into the network as a series of bit streams. Wherein each layer of the data received must add some header information (sometimes increase trailer information)

Illustrated as follows:

 

How to find the target client service

When a client initiates a request, we will assemble at the data link layer to the MAC address of the target machine, the target machine mac address how to get it? Here involves an ARP protocol that is simply known target machine

The ip, need to get mac address of the target machine. (Sending a broadcast message, the ip who is invited claim. Ip claim the machine will send a response mac address) with this destination MAC address, broadcast packets on the link, network card MAC can be found, this package is to it. MAC card to pack closed in, and then open the IP packet, find the IP address is their own, and then open the TCP packet and found port of their own, which is port 80, but this time there is on this machine a nginx is listening on port 80. Thus the request is submitted to Nginx, Nginx returns a page. Then the pages need to send back the machine requests. Then the layers of the package, and finally to the MAC layer. Since the active time to the MAC address, the return time, the source MAC MAC becomes the target, and then returned to the requesting machine. To avoid always use the ARP request, the machine will be local ARP cache. Of course, the machine will keep the ground line off the assembly line, IP may also become, so the MAC address of the ARP cache over time it will expire.

 A receiving end receives the data packet

When the destination host receives a MAC address (destination address and source address), data from the protocol stack begins to rise from the bottom, at the same time remove the packet header plus the protocol layers. Protocols have to check each packet protocol identification in the header to determine the upper layer protocol of the received data.

Why have to go MAC layer IP layer it?

mac address is unique, that in theory, between any two devices, I should be able to by sending data mac address, why do we need ip address? mac address is just like a personal ID number, ID number and city people who account where, date of birth about it and the location where the person does not matter, people will move, knowing a person's ID number, and it can not find the human-like, mac-addr, which is associated with producers and equipment, batch, date and the like and, knowing a device MAC, and it will not send data to the network, unless it is the sender, and within the same network. So to enable communication between machines, we also need to have the concept of ip address, ip address is the expression of the current machine in the network

Network in place, similar to the way the city name + number + concept house number. By addressing ip layer, according to what we know to transfer data between two machines on any path in the world of the Internet. 

TCP and IP layer management

TCP / IP protocol hierarchy according divided into four layers: the application layer, transport layer, network layer, data link layer. For layered concept, such as our distributed architecture system will be divided into the business layer, service layer, base support layer. such as

docker, is implemented through stratification. So we find that complex programs require stratification, this is the software design requirements, each layer of things to focus on the current field. If you need to modify some places, we just need to change the layer replaced on the line, on the one hand changes less impact, on the other hand the flexibility of the entire architecture is also higher. Finally, after stratification, the entire architecture of the design has become relatively simple.

Stratified load

 Floor load

The load floor is for the MAC, server load balancing remains outside a VIP (virtual IP), a cluster of different machines with the same IP address, but the machine's MAC address is not the same. When the server receives a request load balancing, by

Overwrite the destination MAC address of the packet way forwards the request to the target machine load balancing load balancing Layer MAC address will receive requests through a virtual, and then redistributed to the real MAC address

三层负载均衡

三层负载是针对 IP，和二层负载均衡类似，负载均衡服务器对外依然提供一个 VIP（虚 IP），但是集群中不同的机器采用不同的 IP 地址。当负载均衡服务器接受到请求之后，根据不同的

负载均衡算法，通过 IP 将请求转发至不同的真实服务器三层负载均衡会通过一个虚拟 IP 地址接收请求，然后再分配到真实的 IP 地址

四层负载均衡

 四层负载均衡工作在 OSI 模型的传输层，由于在传输层，只有 TCP/UDP 协议，这两种协议中除了包含源 IP、目标 IP 以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受

到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器

七层负载均衡

七层负载均衡工作在 OSI 模型的应用层，应用层协议较多，常用 http、radius、dns 等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个

Web 服务器的负载均衡，除了根据 IP 加端口进行负载外，还可根据七层的 URL、浏览器类别来决定是否要进行负载均衡七层通过虚拟的 URL 或主机名接收请求，然后再分配到真实的服务器。

第二.TCP/IP 协议的深入分析 

2.1TCP握手协议

 TCP 消息的可靠性首先来自于有效的连接建立，所以在数据进行传输前，需要通过三次握手建立一个连接，所谓的三次握手，就是在建立 TCP 链接时，需要客户端和服务端总共发

送 3 个包来确认连接的建立，在 socket 编程中，这个过程由客户端执行 connect 来触发 

第 一 次 握 手(SYN=1, seq=x)客 户 端 发 送 一 个TCP 的 SYN 标志位置 1 的包，指明客户端打算连接的服务器的端口，以及初始序号 X,保存在 包 头 的 序 列 号(SequenceNumber)字段里。发送完毕后，客户端 进 入SYN_SEND 状态。

第 二 次 握 手(SYN=1, ACK=1,seq=y,ACKnum=x+1):服务器发回确认包(ACK) 应 答 。 即SYN 标志位和ACK 标 志 位 均 为1。服务器端选择自

己 ISN 序列号，放到 Seq 域里，同时将 确 认 序 号(Acknowledgement Number)设置为客户的 ISN 加 1，即 X+1。 发送完毕后，服务器 端 进 入

SYN_RCVD 状态。 

第 三 次 握 手(ACK=1 ，ACKnum=y+1)客户端再次发送确认包(ACK)，SYN 标志位为 0，ACK 标志位为 1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，

并且在数据 段放写 ISN 发完毕 后 ， 客 户 端 进 入ESTABLISHED 状态，当服务器端接 收到这个包时，也进 入ESTABLISHED 状态，TCP 握手结束。 

那 TCP 在三次握手的时候，IP 层和 MAC 层在做什么呢？当然是 TCP 发送每一个消息，都会带着 IP 层和 MAC 层了。因为，TCP 每发送一个消息，IP 层和 MAC 层的所有机制都

要运行一遍。而你只看到 TCP 三次握手了，其实，IP 层和 MAC 层为此也忙活好久了。 

SYN 攻击

在三次握手过程中，Server 发送 SYN-ACK 之后，收到 Client 的 ACK 之前的 TCP 连接称为半连接（half-open connect），此时 Server 处于 SYN_RCVD 状态，

当收到 ACK 后，Server转入 ESTABLISHED 状态。SYN 攻击就是 Client 在短时间内伪造大量不存在的 IP 地址，并向Server 不断地发送 SYN 包，Server 回复确认包，

并等待 Client 的确认，由于源地址是不存在的，因此，Server 需要不断重发直至超时，这些伪造的 SYN 包将产时间占用未连接队列，导致正常的 SYN 请求因为队列满而被丢弃，

从而引起网络堵塞甚至系统瘫痪。SYN 攻击时一种典型的 DDOS 攻击，检测 SYN 攻击的方式非常简单，即当 Server 上有大量半连接状态且源 IP 地址是随机的，

则可以断定遭到 SYN 攻击了

TCP 四次挥手协议  四次挥手表示 TCP 断开连接的时候,需要客户端和服务端总共发送 4 个包以确认连接的断开； 客户端或服务器均可主动发起挥手动作(因为 TCP 是一个全双工协议)，在 socket 编程中， 任何一方执行 close() 操作即可产生挥手操作。 

单工：数据传输只支持数据在一个方向上传输半双工：数据传输允许数据在两个方向上传输，但是在某一时刻，只允许在一个方向上传输，实际上有点像切

换方向的单工通信全双工：数据通信允许数据同时在两个方向上传输，因此全双工是两个单工通信方式的结合，它要求发送设备和接收设备都有独立的接收和发送能力

第一次挥手(FIN=1，seq=x)

假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为 1 的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。发送完毕后，客户端进入 FIN_WAIT_1 状态。

第二次挥手(ACK=1，ACKnum=x+1)

服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这

个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。

第三次挥手(FIN=1，seq=w)

服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为 1。发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个 ACK。

第四次挥手(ACK=1，ACKnum=w+1)

客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT 状态，等待可能出现的要求重传的 ACK 包。服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。 客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK，认为服务器端已经正常关闭连接，于是自己也关闭连接，

进入 CLOSED 状态。 假设 Client 端发起中断连接请求，也就是发送 FIN 报文。Server 端接到 FIN 报文后，意思是说"我 Client 端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭 Socket，可以继续发送数据。所以你先发送 ACK，"告诉 Client 端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候 Client 端就进入 FIN_WAIT 状态，继续等待Server 端的 FIN 报文。当 Server 端确定数据已发送完成，则向 Client 端发送 FIN 报文，"告诉 Client 端，好了，我这边数据发完了，准备好关闭连接了"。Client 端收到 FIN 报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕 Server 端不知道要关闭，所以发送 ACK 后 进入 TIME_WAIT 状态，如果 Server 端没有收到 ACK 则可以重传。“，Server 端收到 ACK 后，"就知道可以断开连接了"。Client 端等待了 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭，那好，我 Client 端也可以关闭连接了。Ok，TCP 连接就这样关闭了！

问题

【问题 1】为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：三次握手是因为因为当 Server 端收到 Client 端的 SYN 连接请求报文后，可以直接发送SYN+ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。但是关闭连接时，当 Server 端收到 FIN 报文时，很可能并不会立即关闭 SOCKET（因为可能还有消息没处理 完），所以只能先回复一个 ACK 报文，告诉 Client 端，"你发的 FIN 报文我收到了"。只有等到

我 Server 端所有的报文都发送完了，我才能发送 FIN 报文，因此不能一起发送。故需要四步握手。

 【问题 2】为什么 TIME_WAIT 状态需要经过 2MSL(最大报文段生存时间)才能返回到 CLOSE 状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入 CLOSE 状态了，但是我们必须假

象网络是不可靠的，有可以最后一个 ACK 丢失。所以 TIME_WAIT 状态就是用来重发可能丢

失的 ACK 报文。

2.2阻塞

通过socket.accept 去接收一个客户端请求，accept 是一个阻塞的方法，意味着 TCP 服务器一次只能处理一个客户端请求，当一个客户端向一个已经被其他客户端占用的服务器发送连接请求时，虽然在连接建立后可以向服务端发送数据，但是在服务端处理完之前的请求之前，却不会对新的客户端做出响应，这种类型的服务器称为“迭代服务器”。迭代服务器是按照顺序处理客户端请求，也就是服务端必须要处理完前一个请求才能对下一个客户端的请求进行响应。 但是在实际应用中，我们不能接收这样的处理方式。所以我们需要一种方法可以独立处理每一个连接，并且他们之间不会相互干扰。

一个客户端对应一个线程

为每个客户端创建一个线程实际上会存在一些弊端，因为创建一个线程需要占用 CPU 的资 源和内存资源。另外，随着线程数增加，系统资源将会成为瓶颈最终达到一个不可控的状

态，所以我们还可以通过线程池来实现多个客户端请求的功能，因为线程池是可控的。 

 

非阻塞模型 

上面这种模型虽然优化了 IO 的处理方式，但是，不管是线程池还是单个线程，线程本身的处理个数是有限制的，对于操作系统来说，如果线程数太多会造成 CPU 上下文切换的开销。因

此这种方式不能解决根本问题

阻塞IO

就是当客户端的数据从网卡缓冲区复制到内核缓冲区之前，服务端会一直阻塞。以socket接口为例，进程空间中调用 recvfrom，进程从调用 recvfrom 开始到它返回的整段时间内都是被阻塞的， 因此被成为阻塞 IO 模型

 

 非阻塞IO

就是进程空间调用 recvfrom，如果这个时候内核缓冲区没有数据的话，就直接返回一个 EWOULDBLOCK 错误，然后应用程序通过不断轮询来检查这个

状态状态，看内核是不是有数据过 来。