I am quite impressed with this question, which was asked during the previous interview development. You say it is difficult, in fact, there are standard answers on the Internet. But you said it is not difficult, it is also difficult to explain it in the interview, even if you say it, it is just a stereotyped essay.
When I was asked this question at the beginning, I was thinking "When will I offend the interviewer?" If I asked this question to a newcomer in the workplace, I would definitely be stunned, at least I would ask "What's the use of knowing? You Do you use all seven layers at work? Your company only goes up to the transport layer, what’s wrong with you?…”
Well, although it is useless, I still have to answer what should be answered. I will answer it again according to my own thinking, and remember to answer as many as I can. The OSI seven-layer protocol from bottom to top is:
| OSI level | answer content |
|---|---|
| physical layer | What to do : Define the physical characteristics of the device, such as cables, interface types, etc.; common technologies : various transmission media (twisted pair, optical fiber, etc.), various interfaces and connectors (RJ45, USB, etc.); |
| data link layer | What to do : transfer data frames between hosts in the network, process physical addresses, MAC addresses, etc.; common technologies : Ethernet, FDDI, PPP and other data link layer protocols, VLAN, MAC address, etc.; |
| Network layer | What to do : Responsible for network interconnection and IP addressing; common technologies : IP, ARP, RARP, ICMP, IGMP and other network layer protocols. Routing protocols such as RIP, OSPF, BGP, etc.; |
| transport layer | What to do : Provide end-to-end reliable transmission, handle flow control, retransmission, etc.; common technologies : TCP, UDP and other transport layer protocols and various port numbers; |
| session layer | What to do : Establish, manage and terminate sessions; common technologies : session layer protocols such as PAP and SOCKS; |
| presentation layer | What to do : encrypt and compress data; common technologies : ASCII, TIFF, GIF, PCM and other data representation and encoding formats; |
| application layer | What to do : directly provide network services for the user's application process; common technologies : HTTP, FTP, SMTP, POP3, DNS and other application layer protocols; |
HTTP technology is definitely used the most. HttpClient and OKHttp client are often used in projects, each of which has its own advantages and disadvantages (only represents personal opinions after use):
| client | advantage | shortcoming |
|---|---|---|
| Apache HttpClient | - Widely used, stable and mature- Complete API and powerful functions- Support multi-threading, excellent connection pool management- Support HTTPS, authentication, proxy and other functions |
- The configuration is relatively complicated - The underlying implementation is old and the efficiency is not as good as OkHttp - HTTP/2 is not supported |
| OkHttp | - High performance, fast transmission speed - Support HTTP/2, using multiplexing - Internal implementation using the latest features of Android |
- Not as widely used as Apache HttpClient - Connection pool management is not as perfect as Apache |
Generally speaking, if you are pursuing performance, you can try OkHttp, and the effect is good. But if you want to quickly develop Apache HttpClient is a better choice. Far away, in addition to the client, the Springcloud service communication also uses the HTTP protocol (this should be understood by everyone). It is simple, flexible, easy to expand, and the text display is also easy to debug. I think this should be the communication protocol with the highest usage rate in the application layer.
There are actually many optimizations for HTTP performance, including caching, persistent connections, fragmented transmission, compression, asynchronous transmission, etc., while HTTP/2 and HTTP/3 introduce functions such as multiplexing, header compression, and server push. Further improve HTTP performance. The following four methods I have come into contact with the most are based on server-side optimization methods:
- Compress transmission data: Enable GZIP compression for text data to reduce package size. For multimedia files such as pictures and videos, use the strategy of compressing first and then uploading, rather than uploading the entire file;
- Use CDN: use CDN to cache and distribute static resources, and respond to user requests nearby;
- Adopt HTTP/2: HTTP/2 introduces features such as multiplexing, header compression, and server push, which can effectively optimize HTTP performance;
- Optimizing TCP parameters: generally achieved by adjusting Linux system parameters, for example: increasing the initial congestion window size (Initial Congestion Window). The SOCKET_RCVBUF and SOCKET_SNDBUF parameters are set by setsockopt(). By modifying /proc/sys/net/ipv4/tcp_delayed_ack to set delayed reply to reduce the number of ACK, etc.;
As for the front end, the company has dedicated developers to manage it, but if I manage it, I might:
- Adopt asynchronous technology: use AJAX, HTTP streaming (Streaming) and other asynchronous technologies to improve interactive experience;
- Utilize the cache mechanism: properly set the cache header information such as Cache-Control, Last-Modified, Etag, etc., and make full use of the cache to avoid repeated requests;
- Query string optimization: avoid excessively long query strings, and use POST to submit data;
I guess that's all.