code
:
1 | # coding: utf-8 |
Development Server
$ python3 main.py
1 | $ curl localhost:8080 |
uWSGI
uwsgi.ini
:
1 | [uwsgi] |
nginx
:
1 | server { |
$ uwsgi --ini uwsgi.ini
1 | $ curl localhost |
code
:
1 | # coding: utf-8 |
$ python3 main.py
1 | $ curl localhost:8080 |
uwsgi.ini
:
1 | [uwsgi] |
nginx
:
1 | server { |
$ uwsgi --ini uwsgi.ini
1 | $ curl localhost |
$ nginx -s reload
https://github.com/memcached/memcached See the file BUILD
to learn how to build.
The default configuration file /etc/memcached.conf
is used by scripts/start-memcached
when using this script to start service.
Protocol is described in doc/protocol.txt
.
server
:
1 | $ memcached -vv -m 3 -M |
client
:
1 | $ nc -c localhost 11211 |
server
:
1 | $ memcached -vv -m 3 -M |
client
:
1 | # coding: utf-8 |
1 | $ python3 main.py |
1 | package main |
1 | [2020-05-19 18:21:20] ERROR set error: memcache: unexpected response line from "set": "SERVER_ERROR out of memory storing object\r\n" |
TCP sets a timer when it sends data, and if the data is not acknowledged when the timer expires, a timeout or timer-based retransmission of data occurs. The timeout occurs after an interval called the retransmission timeout (RTO). It has another way of initiating a retransmission called fast retransmission or fast retransmit, which usually happens without any delay. Fast retransmit is based on inferring losses by noticing when TCP’s cumulative acknowledgment fails to advance in the ACKs received over time, or when ACKs carrying selective acknowledgment information (SACKs) indicate that out-of-order segments are present at the receiver. Generally speaking, when the sender believes that the receiver might be missing some data, a choice needs to be made between sending new (unsent) data and retransmitting.
In general, a reset is sent by TCP whenever a segment arrives that does not appear to be correct for the referenced connection. The reset segment elicits no response from the other end—it is not acknowledged at all. The receiver of the reset aborts the connection and advises the application that the connection was reset. This often results in the error indication “Connection reset by peer” or a similar message.
http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html
https://stackoverflow.com/a/60075710/13133551
The two reasons for the existence of the TIME-WAIT state and the 2SML timer:
- If the last ACK segment is lost, the server TCP, which sets a timer for the last FIN (Finish) bit set, assumes that its FIN is lost and resends it. If the client goes to the CLOSED state and closes the connection before the 2MSL timer expires, it never receives this resent FIN segment, and consequently, the server never receives the final ACK. The server cannot close the connection. The 2MSL timer makes the client wait for a duration that is enough time for an ACK to be lost (one SML) and a FIN to arrive (another SML). If during the TIME-WAIT state, a new FIN arrives, the client sends a new ACK and restarts the 2SML timer.
- A duplicate segment from one connection might appear in the next one. Assume a client and a server have closed a connection. After a short period, they open a connection with the same socket addresses (same source and destination IP addresses and the same source and destination port numbers). A duplicated segment from the previous connection may arrive in this new connection and be interpreted as belonging to the new connection if there is not enough time between the two connections. To prevent this problem, TCP requires that an incarnation cannot occur unless a 2MSL amount of time has elapsed.
http://www.networksorcery.com/enp/protocol/tcp/option008.htm
This field contains the current value of the timestamp clock of the TCP sending the option.
This field is only valid if the ACK bit is set in the TCP header. If it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option. When TSecr is not valid, its value must be zero. The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below. A TCP may send the Timestamp option in an initial SYN segment (i.e., segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it received a TSopt in the initial SYN segment for the connection.
server
:
1 | In [1]: import socket |
client
1 | In [1]: import socket |
netstat
1 | $ netstat -tan | grep 30002 |
tcpdump
1 | $ sudo tcpdump -ilo "tcp and port 30002" -v -X |
Little and big endian are two ways of storing multibyte data-types ( int, float, etc). In little endian machines, last byte of binary representation of the multibyte data-type is stored first. On the other hand, in big endian machines, first byte of binary representation of the multibyte data-type is stored first.
1 | #include <bits/stdc++.h> |
https://stackoverflow.com/a/997586/13133551
"Network byte order" is Big Endian, and protocols such as TCP use this for integer fields (e.g. port numbers). Functions such as htons and ntohs can be used to do conversion.
The data itself doesn't have any endianness it's entirely application defined.
As we can see from the picture, the endianness of net is Big Endian.
Each label can be up to 63 characters long, and an entire FQDN(fully qualified domain name) is limited to at most 255 (1-byte) characters.
1 | $ dig baidu.com |
1 | $ dig +trace baidu.com |
1 | $ dig |
We can see the response of $ dig @ns2.baidu.com. baidu.com
have aa
flag set.