Computer network
-
TCP application scenarios UDP application scenarios
-
TCP: Applies to applications that require reliable transmission, such as file transmission
-
UDP: Suitable for real-time applications (IP phone, video conference, live broadcast, etc.)
-
-
How to solve the browser limit on the number of HTTP requests for the same domain name
-
With HTTP2, you only need to establish a TCP connection, and multiple requests and responses are transmitted as frames
-
If multiple domain names are bound to the same server and different domain names are used for front-end requests, the maximum number of TCP concurrent requests imposed by the browser can be 6-8
-
-
Can the three-way handshake carry data
-
Symptom A SYN packet is sent for the first handshake, but the client does not establish a TCP connection
-
After receiving the SYN packet, the server sends an ACK + SYN packet, indicating that it agrees to establish a connection and requests to establish a connection between the server and the client. In this case, the server establishes resources for the TCP connection
-
After receiving the ACK + SYN packet from the server, the client establishes resources related to TCP. In this case, both the client and the server establish TCP connections. Therefore, the third ACK packet can carry data
-
-
UDP header format
- UDP header.
-
Source port number: indicates the sending port number. The field length is 16 bits. This field is optional, and sometimes the source port numbers may be set to all zeros. Indicates that no reply is required
-
Destination port number: indicates the port number of the receiving end. The field length is 16 bits.
-
Packet length: This field stores the sum of the length of the UDP header and the data length. The unit is byte.
-
Checksum: Checksum is designed to provide reliable UDP headers and data.
-
TCP header format
- The TCP header
-
Source port/Destination port: TCP is mainly responsible for the communication between two applications. After data is sent to the destination computer, it needs to know which application needs to be delivered. Therefore, the port number is required to specify which two processes are communicating with each other
-
Serial number: Indicates the number of the first byte of the data to be sent in the packet. Since the serial number is represented by 32 bits, sequence number winding occurs every 2^32 bytes, again starting at 0
-
Acknowledgement number: indicates the number of the first byte of the next packet segment that the receiver expects to receive from the sender.
-
Data offset: indicates the distance between the start of the TCP packet and the start of the TCP packet, that is, the length of the TCP header. The unit of this field is 32 bits (that is, 4 bytes as a unit of calculation), 4 bits of binary represents a maximum of 15, so the data offset or TCP header is a maximum of 60 bytes
-
URG: Indicates whether the data sent in this paragraph contains urgent data. The following urgent Pointer field is valid only if URG=1
-
ACK: indicates whether the confirmation number field is valid. The preceding confirmation number field is valid only if ACK=1. According to TCP, after a connection is established, the ACK value must be 1. The TCP packet segment with the ACK flag is called the acknowledgment packet segment
-
PSH: indicates that the receiving application should immediately read data from the TCP receive buffer to make room for subsequent data to be received. If the value is 1, the peer should immediately submit the data to the upper-layer application rather than cache it. If the application does not read away the received data, it will remain in the TCP receive buffer
-
RST: If a packet with RST=1 is received, it indicates that a serious error occurs in the connection with the host (for example, the host crashes). The connection must be released and re-established. Or it indicates that the data sent to the host last time is faulty and the host refuses to respond. The TCP packet segment with the RST flag is called the reset packet segment
-
SYN: Used during connection establishment to synchronize serial numbers. When SYN=1, ACK=0, it indicates that this is a packet segment requesting to establish a connection. When SYN=1 and ACK=1, the peer party agrees to establish a connection and requests to establish a connection. A TCP packet segment with the SYN flag is called a synchronous packet segment
-
FIN: notifies the peer end of closing the connection and marks whether data is sent. If the VALUE of FIN is 1, the peer is told, “My data has been sent and you can release the connection.” A TCP packet segment with the FIN flag is the end segment
-
Window size: indicates the amount of data that the other party is allowed to send, that is, to tell the other party the amount of data that the other party is allowed to send from the confirmation number of this article. When the value reaches this value, the next data can be transmitted only after ACK confirmation.
-
Checksum: Provides additional reliability by validating data for errors
-
Emergency pointer: Marks the position of emergency data in a data field
-
Option: The maximum length can be calculated according to the length of the TCP header. The length of the TCP header is 4 bits. The maximum length of the option part is :(2^4-1) x 4-20=40 bytes
-
Maxium Segment Size (MSS), usually 1460 bytes, specifies the expected length of the data field when the peer sends a TCP Segment.
-
Window expansion: Window Scale. As the communication with large delay and bandwidth is generated, larger Windows are required to meet the performance and throughput
-
Timestamps: this parameter is used to calculate RTT. When the sender sends a TCP packet, it puts the current time in the timestamp field. When the receiver sends an acknowledgement packet, the time stamp field is copied to the acknowledgement packet.
-
-
Data: TCP packet header
-
How does TCP ensure reliable transmission
-
TCP wave three times, wave four times, fully ensure that the connection is successfully established and successfully disconnected
-
Checksum: verifies and checks the TCP packet header. If transmission error occurs, the packet is discarded and ICMP sends an error message
-
Timeout retransmission: When the sender does not receive the ACK data from the recipient, the packet is lost by default and will be retransmitted
-
Traffic control: Adjusts the sending rate when the network is in bad condition to avoid discarding packets when the route cache queue is full
-
-
HTTP caching mechanism
-
Only resources obtained by GET requests can be cached
-
Cache-Control
-
Public: Resources can be cached by any intermediate node (client and proxy server)
-
Private: Only clients can Cache. The default value of cache-control
-
Max-age =< seconds > : indicates that the cache will be invalid in XXX seconds
-
S-maxage =< seconds > : this parameter takes effect only on the proxy server (for example, CDN cache). S-maxage has a higher priority than max-age. If s-maxage is set and public is not set, the proxy server can also cache the resource (because s-maxage is only used by the proxy server, and the proxy server must be public to cache the resource).
-
No-cache: You can cache, but you must go to the server each time to verify whether the cache is available and enter the negotiation cache stage. Instead of using cache-control for pre-validation, use Etag or Last-Modified fields to Control the Cache. Equivalent to max-age:0, must-revalidate
-
No-store: All content is not cached, that is, neither mandatory cache nor negotiated cache is used
-
Must -revalidate: cacheable but must be validated to the source server
-
Proxy-revalidate: requires the intermediate cache server to confirm the validity of the cached response
-
-
Strong cache
-
Initially, this is determined by the expires returned by the server, which is a timestamp that indicates when the cache will expire. Until then, the browser reads directly from the cache and does not request resources from the server
-
Later, when an expires expires is found to be insufficient, such as when the client time is inconsistent with the server time, the cache expiration date cannot be determined. So now use the max-age of cache-control to set the expiration time. However, the use of Expires is retained for downward compatibility
-
The value of max-age in cache-control is a relative time, for example, cache-control: max-age=30. The Date in the return header indicates the time when the message is sent, indicating that the current resource is valid for the period from Date to Date +30s. If the user accesses the resource again within 30 seconds, the user uses the local cache and does not send requests to the server.
-
Cache-control takes precedence over Expires
-
-
Negotiate the cache
-
Cache-control is set to no-cache, which means that you should go to the server every time to verify that the Cache is available.
-
If expires or max-age expires, it also validates the cache to the server, which is the same as negotiating the cache
-
The server response header contains Etag and last-Modified, indicating the file hashing time and the Last modification time, respectively
-
If a client requests an if-not-match (Etag), if-modified-since (last-modified) header
-
If the server determines that the cache is still available, it does not return any resources, status code 304, indicating that the negotiated cache is available
-
-
-
How do I control HTTP caching
-
A better use of HTTP caching mechanism can reduce requests, use more local resources, give users a better experience at the same time, but also reduce the pressure on the server. The best practice is to hit strong caches as much as possible and invalidate client caches with updates
-
The current strategy is to use a negotiated cache for HTML, a strong cache for CSS, JS, and images, and a hash value for file names.
-
The reason is that when the page is updated, the HTML is negotiated by the cache, so you can definitely get the latest page. In the case of CSS, JS, and image packaging, because the file name has hash value, if the file has been modified, the requested link will be different, equivalent to the first request, and the latest resources will be pulled from the server again
-
Set strong cache:
res.setHeader('Cache-Control'.'public, max-age=xxx'); Copy the code
- Setting the Negotiation Cache
res.setHeader('Cache-Control'.'public, max-age=0'); // If strong cache expires, negotiation cache is used, or public, no-cache is set directly res.setHeader('Last-Modified', xxx); res.setHeader('ETag', xxx); Copy the code
- Data: HTTP caching mechanism
-
-
HTTP request composition
- The starting line
- Request methods, such as GET and POST
- Request target: URL
- HTTP version number
- header
- request headers
- general headers
- entity headers
- Body: request body
- The starting line
-
What is CDN and how does it work
-
CDN is the content distribution network, which can intelligently cache the content of the source site to each node server around the world, which is convenient for users to obtain the content nearby and share the pressure of the source site
-
Related terms:
- A Record: Mapping records from domain names to IP addresses
- CNAME records: Mapping records from domain names to domain names
- NS record: Specifies the DNS server that resolves the domain name.
-
Access process:
- Assume that the domain name of the working server is www.tt.com
- Apply for an accelerated domain name, js.tt.com, from a domain vendor
- To the CDN platform, such as Ali Cloud CDN, add the acceleration domain name js.tt.com, and set the source domain name as www.tt.com
- Configure js.tt.com.ali.com assigned by Ali Cloud CDN to the CNAME record of js.tt.com
-
CDN system architecture
- CDN system is mainly divided into edge layer and center layer
- The edge layer is distributed at the edge of THE CDN network to provide users with nearby access services.
- The central layer is responsible for resource synchronization and operation management. The central layer stores the configuration information of the accelerator domain name, such as the source domain name, and caches various resources under the accelerator domain name.
- If the edge layer node fails to hit the cache, a request needs to be sent to the center layer node. If the central layer node fails to match the cache, it needs to search for the corresponding source domain name and send a request to the source domain name. The resource requested by the user is then returned and cached layer by layer.
-
User A accesses the flow for the first time
- X.X.X.X refers to the edge layer node server that is close to the user and is dynamically determined by the CDN
-
User A accesses the IP address for the second time
- Js.tt.com = js.tt.com = js.tt.com = js.tt.com = js.tt.com = js.tt.com = js.tt.com = js.tt.com
-
User B accesses the IP address for the first time
- X does not represent the same edge layer node. In this case, the edge layer node accessed by USER B has no cache. Therefore, the cache needs to be obtained from the central layer
-
Why visit js.tt.com.ali.com and get IP of edge layer server
- First go to js.tt.com. Since CNAME is configured, the result of parsing is js.tt.com.ali.com
- Js.tt.com.ali.com is configured with NS, handing the resolution of this domain name to the DNS server configured by the CDN provider
- The DNS server then returns an edge layer node server IP address that is closer to the user
-
Data: CDN working principle introduction
-
-
What happens from entering the URL to displaying the page
-
Building an HTTP request
- The first message
- Message body
-
Strong cache lookup
-
The DNS
-
Establishing a TCP Connection
-
Making an HTTP request
-
Negotiate the cache
-
Get a response
-
Build a DOM tree
-
Build CSSOM tree
-
Building a Render tree
-
Return to redraw
-
Source: Detail what happens when you enter the URL to display the content on the page
-