Normal TCP Close Phases

https://accedian.com/blog/close-tcp-sessions-diagnose-disconnections/

Figure 1 – Simplified TCP closing with FIN.

The standard way to close TCP sessions is to send a FIN packet, then wait for a FIN response from the other party.

1. A sends a FIN packet and waits for a response; it can release some resources but awaits the response of the other part (Fin Wait)
2. B receives the FIN packet and must release resources; it waits for a closing application level (Close Wait)
3. B can now send a FIN to A and then await its acknowledgement (Last Ack wait).
4. A can now fully close its job, but it must wait for network collision (?) (Time Wait); it may have to send the final ACK another time.
5. B eventually receives the final ACK and destroys (kills) the connection.

This works fine in a perfect world. However, what happens when one part of the conversation is broken? That’s why the Reset (RST) packet exists.

https://accedian.com/blog/diagnose-tcp-connection-setup-issues/

A TCP connection, also called 3-way Handshake is achieved with SYN, SYN+ACK and ACK packets. From this handshake, we can extract a performance metric called Connection Time (CT), which summarizes how fast session a can be set up between a client and a server over a network. For more details, see this excellent article on Wikipedia.

• 从linux源码看socket(tcp)的timeout

https://danielw.cn/cache-consistency-with-database

https://www.sciencedirect.com/topics/computer-science/cache-consistency

raft

http://thesecretlivesofdata.com/raft/

https://raft.github.io/

CAP

BASE

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent(最终一致性)三个短语的简写

复制状态机

https://zhuanlan.zhihu.com/p/86999794

复制状态机的思想是一个分布式的复制状态机系统由多个复制单元组成，每个复制单元均是一个状态机，它的状态保存在一组状态变量中。状态机的状态能够并且只能通过外部命令来改变。

分布式一致性

Paxos

Multi-Paxos

Raft

EPaxos

对比分析

https://developer.aliyun.com/article/768655

1 可理解性

众所周知，Paxos是出了名的晦涩难懂，不仅难以理解，更难以实现。而Raft则以可理解性和易于实现为目标，Raft的提出大大降低了使用分布式一致性的门槛，将分布式一致性变的大众化、平民化，因此当Raft提出之后，迅速得到青睐，极大地推动了分布式一致性的工程应用。

架构设计之「服务限流」

二、服务限流应该怎么做？
对系统服务进行限流，一般有如下几个模式：

1. 熔断：
   这个模式是需要系统在设计之初，就要把熔断措施考虑进去。当系统出现问题时，如果短时间内无法修复，系统要自动做出判断，开启熔断开关，拒绝流量访问，避免大流量对后端的过载请求。系统也应该能够动态监测后端程序的修复情况，当程序已恢复稳定时，可以关闭熔断开关，恢复正常服务。
2. 服务降级：
   将系统的所有功能服务进行一个分级，当系统出现问题，需要紧急限流时，可将不是那么重要的功能进行降级处理，停止服务，这样可以释放出更多的资源供给核心功能的去用。
   例如在电商平台中，如果突发流量激增，可临时将商品评论、积分等非核心功能进行降级，停止这些服务，释放出机器和CPU等资源来保障用户正常下单，而这些降级的功能服务可以等整个系统恢复正常后，再来启动，进行补单/补偿处理。
   除了功能降级以外，还可以采用不直接操作数据库，而全部读缓存、写缓存的方式作为临时降级方案。
3. 延迟处理：
   这个模式需要在系统的前端设置一个流量缓冲池，将所有的请求全部缓冲进这个池子，不立即处理。然后后端真正的业务处理程序从这个池子中取出请求依次处理，常见的可以用队列模式来实现。这就相当于用异步的方式去减少了后端的处理压力，但是当流量较大时，后端的处理能力有限，缓冲池里的请求可能处理不及时，会有一定程度延迟。
4. 特权处理：
   这个模式需要将用户进行分类，通过预设的分类，让系统优先处理需要高保障的用户群体，其它用户群的请求就会延迟处理或者直接不处理。

那在实际项目中，对访问流量的限制，可采用如下几种技术方法：

Streams, messages, and frames

https://developers.google.com/web/fundamentals/performance/http2

The introduction of the new binary framing mechanism changes how the data is exchanged between the client and server. To describe this process, let’s familiarize ourselves with the HTTP/2 terminology:

• Stream: A bidirectional flow of bytes within an established connection, which may carry one or more messages.
• Message: A complete sequence of frames that map to a logical request or response message.
• Frame: The smallest unit of communication in HTTP/2, each containing a frame header, which at a minimum identifies the stream to which the frame belongs.

The relation of these terms can be summarized as follows:

curl http2

https://http2-explained.haxx.se/en/part11

11.1. HTTP 1.x look-alike

Internally, curl will convert incoming http2 headers to HTTP 1.x style headers and provide them to the user, so that they will appear very similar to existing HTTP. This allows for an easier transition for whatever is using curl and HTTP today. Similarly curl will convert outgoing headers in the same style. Give them to curl in HTTP 1.x style and it will convert them on the fly when talking to http2 servers. This also allows users to not have to bother or care very much with which particular HTTP version that is actually used on the wire.

https://pi3g.com/2019/01/17/envoy-as-http-2-front-proxy-enabling-http-2-for-envoy-aka-h2/

envoy as http 2 front proxy – enabling http 2 for envoy (aka h2)

By Maximilian Batz | 2019-01-17

Out of the box envoy is not configured to set up connections with clients connecting to it with the new HTTP/2.

HTTP/2 is optimized for the modern web, with binary headers, etc. – higher speed.

Since envoy is capable of speaking HTTP/2 to clients, it is a no-brainer to set it up.

Header case

https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2

8.1.2. HTTP Header Fields

HTTP header fields carry information as a series of key-value pairs.
For a listing of registered HTTP headers, see the “Message Header
Field” registry maintained at <https://www.iana.org/assignments/
message-headers>.

Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. A request or response containing uppercase header field names MUST be treated as malformed (Section 8.1.2.6](https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.6)).