preface
An Awesome Android Expert Interview Questions and Answers (Continuous Updating)
From dozens of top interview warehouse and more than 300 high-quality interviews summarized a comprehensive and systematic Android advanced interview test set.
With the development of Android technology, Kotlin, the big front-end technologies Flutter, RN, small programs and so on have suddenly come into our view. At the same time, Android’s own technology stack is also expanding, such as the popular Jetpack in foreign countries. Therefore, Android developers are more and more anxious, more and more confused, everyone’s time and energy is limited, what should we learn to effectively improve their competitiveness? In fact, first of all, we should give priority to in-depth study of the technology used in work. Secondly, we should pay attention to the knowledge points involved in the latest Android interview questions in the past two years, and selectively study and improve according to our actual situation. Only in this way, they will not be intimidated by the so-called Internet winter. Awesome-Android-Interview has collected the most common Interview questions from first-line and second-line Internet companies in China, and it is very comprehensive. I hope that you can systematically and repeatedly learn them, so as to quickly improve yourself. I have spent a lot of energy and time on this article, and I hope to get your support. Android interview questions often involve the following aspects:
- 1, computer basic: TCP/IP, HTTP/HTTPS, Socket, (Linux) operating system, database related.
- 2, Java basics: Object-oriented, reflection, generics, collection library related.
- Java concurrency: Threads/thread pools, volatile, pessimistic/optimistic locks, etc.
- 4, Jvm virtual machine: such as execution process, JMM model, Java GC recycling principle, class loader.
- 5. Data structure and algorithm: Offer + LeetCode
- 6. Android Basics: startup mode, animation, custom View.
- 7. Android Advanced: Performance optimization, Binder, AIDL, interprocess communication, AMS/WMS/PMS, event distribution, sliding conflict, View drawing process, important Android source and open source library analysis.
- 8, Android high and new technology: modularization, componentization, hot update, plug-in implementation principle.
- 9. Finally, it’s a plus if you know other development methods or languages. Things like Flutter, ReactNative, Python, front and back end development.
directory
In 2020 senior Android factory interview secrets, for you to escort gold three silver four, through dafang (computer foundation)
2020 senior Android factory interview secrets, for you to escort gold three silver four, through the factory (Java)
2020 senior Android factory interview secrets, for you to escort gold three silver four, through the factory (Android basic)
2020 senior Android factory interview secrets, for you to escort gold three silver four, through the factory (Android advanced)
In 2020 senior Android factory interview secrets, for you to escort gold three silver four, through the factory (Android advanced chapter ii)
The interview is just like the exam, just like what we do before the college entrance exam, nothing more than to understand and remember every knowledge point. To pass the interview of course need certain skills, but is not to rely on forgery and blowing cheating, through a period of time to sink down to close practice, wait until spring, you can harvest, into the big factory, salary doubled, isn’t it beautiful?
Note: The frequency of each knowledge point corresponding to the interview questions is divided into three levels according to the grade of ⭐, namely ⭐, ⭐⭐ and ⭐⭐⭐. If time is sufficient, it is recommended to understand at least ⭐⭐ and t. If time is urgent, it is recommended to understand T.
For better classification learning, it is recommended to jump to the corresponding Github address of this project, welcome Star, Fork, Watch~
Finally, borrow a pair of dailang grade salary map on the pulse, add more oil to everyone’s locomotive, I wish you a smooth drive, bon voyage ~
Computer network
1. HTTP/HTTPS (⭐⭐⭐)
1. What’s the difference between HTTP and HTTPS?
HTTPS is a transport protocol for secure communication over computer networks. HTTPS communicates over HTTP, but uses SSL/TLS to encrypt packets. The main purpose of HTTPS development is to provide identity authentication for web servers and protect the privacy and integrity of exchanged data.
HTPPS and HTTP concepts:
Hypertext Transfer Protocol Over Secure Socket Layer (HTTPS) is an HTTP channel with the goal of security. It is simply the Secure version of HTTP. The SSL layer is added to HTTP. The security basis of HTTPS is SSL, so the detailed content of encryption needs SSL. It is a URI Scheme (abstract identifier system), syntactically similar to the HTTP: system. Used for secure HTTP data transfer. HTTPS: THE URL indicates that HTTP is used, but HTTPS has a different default port from HTTP and an encryption/authentication layer (between HTTP and TCP). Originally developed by Netscape, the system provides authentication and encrypted communications, and is now widely used for security-sensitive communications on the World Wide Web, such as transactions and payments.
HTTP-Hypertext Transfer Protocol (HTTP-Hypertext Transfer Protocol) is a data transfer protocol that specifies the rules for communication between the browser and the World Wide Web server and transmits World Wide Web documents over the Internet.
For HTTPS, you need to apply for a certificate from the CA. Generally, there are few free certificates and you need to pay a fee. HTTP is the hypertext transfer protocol, the information is transmitted in plain text, and HTTPS is the secure SSL encrypted transfer protocol. HTTP and HTTPS use a completely different connection mode and a different port, 80, 443. HTTP is a simple, stateless connection. HTTPS is a network protocol built by SSL+HTTP. It can be used for encrypted transmission and identity authentication. The trust host problem. An HTTPS server must apply for a certificate from the CA to prove the server’s purpose type. The client trusts the secondary host only when the certificate is used for the corresponding server 2. Prevent data leakage and tampering during communication
As shown in the figure below, the difference between the two can be clearly seen:
Note: TLS is an upgraded alternative to SSL. For details, see transport Layer Security.
The difference between HTTP and HTTPS is that the prefix is different and the client handles it differently. To be specific:
If the URL protocol is HTTP, the client opens a connection to the server port 80 (default) and sends the old HTTP request to it. If the URL protocol is HTTPS, the client opens a connection to the server port 443 (default) and then shakes hands with the server to exchange some SSL security parameters in binary format with the server, along with an encrypted HTTP request. So as you can see, HTTPS has one more layer of SSL connection than HTTP. This is the SSL handshake between client and server. The whole process does the following:
Switching Protocol Version Number Select a password known by both ends. Authenticate the identities of both ends. Generate a temporary session key for encrypting the channel. The SSL handshake is a relatively complex process. For more details about the SSL handshake, refer to the TLS/SSL handshake process
A common open source implementation of SSL/TSL is OpenSSL. OpenSSL is an open source software library package that applications can use to communicate securely, avoid eavesdropping, and verify the identity of the person on the other end of the connection. This package is widely used in Web servers on the Internet. For more technical details from OpenSSL, see OpenSSL.
What are the differences between Http1.1 and Http1.0 and 2.0?
Some differences between HTTP1.0 and HTTP1.1
HTTP1.0 was first used on web pages in 1996 for simple web pages and web requests, while HTTP1.1 began to be widely used for web browser requests in 1999, and HTTP1.1 is currently the most widely used HTTP protocol. The main differences are as follows:
-
Caching. HTTP1.0 mainly uses if-modified-since,Expires in headers as the standard for caching. HTTP1.1 introduces more cache control policies such as Entity Tag. If-unmodified-since, if-match, if-none-match, and many more alternative cache headers to control cache policies.
-
2, use of bandwidth optimization and network connection, HTTP1.0, there are some waste of the bandwidth, the client just need to be part of an object, for example, while the server to send the entire object, and does not support breakpoint continuingly functions, while the HTTP1.1 requests first introduced the range domain, which allows only a part of the request resources, The return code is 206 (Partial Content), which gives the developer the freedom to make the most of the bandwidth and connection.
-
3, the management of error notification, in HTTP1.1 added 24 error status response code, such as 409 (Conflict) indicates that the requested resource and the current state of the resource Conflict; 410 (Gone) Indicates that a resource on the server has been permanently deleted.
-
4. Host header processing. HTTP1.0 assumes that each server is bound to a unique IP address, so the URL in the request message does not pass hostname. However, with the development of virtual hosting technology, there can be multiple homed Web Servers on a physical server, and they share an IP address. HTTP1.1 should support the Host header field in both Request and response messages, and a Request message without the Host header field will report an error (400 Bad Request).
-
PersistentConnection. HTTP 1.1 supports Pipelining and PersistentConnection processing. Multiple HTTP requests and responses can be transmitted over a SINGLE TCP connection, reducing the consumption and latency of establishing and closing connections. Connection: keep-alive is enabled by default in HTTP1.1, to some extent compensating for HTTP1.0’s requirement to create a Connection on every request.
SPDY
Before talking about the differences between Http1.1 and Http2.0, SPDY is an optimization for Http1.x:
In 2012, Google proposed SPDY, which optimized http1.x request latency and solved the security of Http1.x. The details are as follows:
-
1, reduce latency, for HTTP high latency problems, SPDY elegant multiplexing. Multiplexing solves the blocking problem by sharing a TCP connection with multiple request streams, reduces the delay and improves the utilization rate of bandwidth.
-
Request priorities will be prioritized. A new problem with multiplexing is that critical requests can be blocked on the basis of connection sharing. SPDY allows you to set a priority for each request so that the most important requests get the first response. For example, when the browser loads the home page, the HTML content of the home page should be displayed first, and then all kinds of static resource files and script files are loaded, so as to ensure that users can see the content of the web page in the first time.
-
3. Header compression. The http1.x headers mentioned earlier are often redundant. Choosing the right compression algorithm can reduce the size and number of packets.
-
4, HTTPS based encryption protocol transmission, greatly improve the reliability of data transmission.
-
For example, my web page has a request of sytl. CSS. When the client receives the data of sytl. CSS, the server will push the file of sytl. js to the client. When the client tries to get sytle.js again, it can get it directly from the cache without making a request. SPDY composition diagram:
SPDY is located below HTTP and above TCP and SSL, which makes it easy to work with older VERSIONS of THE HTTP protocol (encapsulating http1.x contents into a new frame format) while using existing SSL capabilities.
New features of HTTP2.0 compared to Http1.x
-
With the new Binary Format, http1.x parsing is text-based. There are natural defects in format parsing based on text protocol. There are various forms of text, so there must be many scenarios to consider robustness. Unlike binary, only combinations of 0 and 1 are recognized. Based on this consideration of HTTP2.0 protocol resolution decided to use binary format, convenient and robust implementation.
-
MultiPlexing, or connection sharing, means that each request is used as a connection sharing mechanism. A request corresponds to an ID. In this way, a connection can have multiple requests, and the requests of each connection can be randomly mixed together. The receiver can assign the request to different server requests according to the ID of the request.
-
Header compression, as mentioned above, uses encoder to reduce the size of the header that needs to be transmitted. Each side of the communication cache a header fields table. Not only avoids duplicate header transfers, but also reduces the size of transfers needed.
-
Server push, like SPDY, HTTP2.0 also has server push functionality.
For a deeper understanding click here
3. The solution to slow Https requests
1. The IP address is directly accessed without DNS resolution
2. Solve connection reuse problems
The HTTP /1.0 header can set Connection: keep-alive or Connection:Close to allow the Connection to be multiplexed within a certain period of time (the time can be controlled by the server). However, this does not work well for App requests, which are scattered and have a relatively long time span.
Scheme 1. Long link based on TCP (main) mobile terminal to establish a own long link channel, the implementation of the channel is based on TCP protocol. TCP based socket programming technology is relatively complex, and need to customize their own protocols. But information can be reported and pushed in a more timely manner, and request outbreaks can be timed to reduce server stress (avoiding frequent connection creation and destruction).
Solution 2. The HTTP long-polling client sends a polling request to the server in the initial state. The server does not return service data immediately, but returns when new service data is generated, so the link is always maintained. Once the current connection is closed, a new polling request is immediately sent and repeated to ensure that a connection is maintained. Problems: 1) Increased pressure on the server; 2) In a complex network environment, it is necessary to consider how to rebuild a healthy connection channel; 3) The method of polling is not stable; 4) The response of polling may be cached by an intermediate agent……
Solution 3. HTTP streaming is different from long-polling. Streaming uses Transfer Encoding:chuncked in the header of the server response to tell the client that there is a problem with the arrival of new data: 1) Some proxy servers will wait for the server’s response to end before pushing the result to the requesting client. Response 2) Service data cannot be divided according to the request……
Solution 4. The Web socket is similar to the traditional TCP socket. It provides a two-way data channel based on the TCP protocol. It has the advantage of providing the message concept, which is simpler to use than byte stream-based TCP sockets. The technology is relatively new and not all browsers support it.
3, solve the head of line blocking
The reason for this is that the first packet in the queue (the queue header) is blocked, causing the whole column of packets to be blocked
Use HTTP pipelining to ensure that the request is sent to the server almost at the same time
4, Http request and response protocol composition
1. Composition of Request
When a client sends an HTTP request to the server, the request message includes the following format:
Request line, header, blank line and request data are four parts.
The request line begins with a method symbol, separated by a space, followed by the requested URI and the protocol version.
Get Request Example
GET / 562 f25980001b1b106000338. HTTP / 1.1 JPG Host img.mukewang.com the user-agent Mozilla / 5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Accept image/webp,image/*,*/*; Q =0.8 Referer http://www.imooc.com/ accept-encoding gzip, deflate, SDCH accept-language zh-cn,zh; Q = 0.8Copy the code
The first part, the request line, describes the request type, the resource to be accessed, and the HTTP version to be used. The GET request type for the GET, [/ 562 f25980001b1b106000338. JPG] to access resources, is the last part of the bank use HTTP1.1 version. The second part: the request header, the part immediately after the request line (that is, the first line) that specifies the additional information that the server will use. User-agent, accessible to both server-side and client-side scripts, is an important foundation for browser type detection logic. This information is defined by your browser and automatically sent in each request, etc. Part 3: Blank line, blank line after the request header is required even if the request data in part 4 is empty. Part four: Request data, also called the body, can be added to any other data. The request data for this example is empty.
POST Request Example
POST/HTTP1.1 Host:www.wrox.com User-agent :Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; The.net CLR 2.0.50727; The.net CLR 3.0.04506.648; NET CLR 3.5.21022) Content-type: Application/x-wwW-form-urlencoded content-length :40 Connection: Keep-Alive name=Professional%20Ajax&publisher=WileyCopy the code
Part one: The request line, the first line is clearly the POST request, and the Http1.1 version.
Part 2: Request header, lines 2 through 6.
Part three: blank line, blank line 7.
Part four: Request data, line 8.
2
Normally, the server receives and processes the request from the client and returns an HTTP response message.
The HTTP response also consists of four parts: the status line, the message header, the blank line, and the response body.
Part one: status line, consisting of HTTP protocol version number, status code, and status message.
The first behavior status line, (HTTP/1.1) indicates the HTTP version is version 1.1, the status code is 200, and the status message is (OK)
Part two: the message header, which describes some additional information that the client will use
The second and third lines act as message headers, Date: The Date and time the response was generated; Content-type: Specifies the MIME Type of HTML(text/ HTML). The encoding Type is UTF-8
Part three: blank lines. Blank lines after the message header are required
Part four: The response body, the text message that the server returns to the client.
The HTML section following the blank line is the body of the response.
Talk about HTTP caching.
The HTTP caching mechanism also depends on the parameter classes in the request and response headers. The final response is pulled from the cache or from the server. The process of the HTTP caching mechanism is as follows:
HTTP caches can be divided into two types:
Mandatory caching: The server needs to be involved in determining whether to continue using the Cache. When the client first requests the data, the server returns the expiration time (Expires and cache-control). If the data is not expired, the Cache can continue to be used. Contrast cache: When the client requests data for the first time, the server returns the cache identifier (last-modified/if-modified-since and Etag/ if-none-match) along with the data. The client backs up both to the cache. When requesting data again, the client sends the cache id of the last backup to the server. The server makes a judgment based on the cache ID. If 304 is returned, the client is notified that the cache can continue to be used. Force caching takes precedence over contrast caching.
The above mentioned two flags to force the cache to use:
Expires: The Expires value is the expiration time returned by the server. That is, when the request time is less than the expiration time returned by the server, the cached data is directly used. The expiration time is generated by the server, and the client and server may have errors. Cache-control: Expires has a time verification problem. All HTTP1.1 uses cache-control instead of Expires. The value of cache-control can be:
Private: The client can cache. Public: Both the client and proxy server can cache. Max-age = XXX: The cached content will become invalid after XXX seconds no-cache: a comparison cache is required to verify the cached data. No-store: Nothing will be cached, neither force caching nor comparison caching will be triggered. Let’s look at comparing the cache’s two identifiers:
Last-Modified/If-Modified-Since
Last-modified Indicates the time when the resource was Last Modified.
When the client sends the first request, the server returns the last time the resource was modified:
Last-Modified: Tue, 12 Jan 2016 09:31:27 GMT
Copy the code
When the client sends it again, it carries if-modified-since in the header. Uploads the last resource time returned by the server to the server.
If-Modified-Since: Tue, 12 Jan 2016 09:31:27 GMT
Copy the code
Server receives the modification time from the client resources, and their current resources, comparing the modification time if their resources from the modification time is greater than the client resources, modified time, then resources change, it returns 200 say need to request resources, otherwise returns 304 indicates resource has not been modified, can continue to use the cache.
The preceding method indicates whether a resource has been Modified with a timestamp, and another method indicates whether a resource has been Modified with an ETag. If the ETag changes, the resource has been Modified, and the ETag has a higher priority than last-Modified.
Etag/If-None-Match
Copy the code
ETag is a resource file identifier. When the client sends the first request, the server returns the current resource identifier:
ETag: "5694c7ef-24dc"
Copy the code
If the client sends it again, it will carry the resource id that the server returned last time in the header:
If-none-match :” 5694C7EF-24dc “If the server receives the resource ID from the client, it compares the resource id with its own. If the resource ID is different, it indicates that the resource has been modified, then it returns 200. If the resource ID is the same, it indicates that the resource has not been modified, then it returns 304. The client can continue to use the cache.
6. Http persistent connection.
Http1.0 is a short Connection, HTTP1.1 is a long Connection by default, which means that the default Connection value is keep-alive. But persistent connections are essentially TCP connections, not HTTP connections. TCP connection is a two-way channel that can be kept open for a period of time, so there are real long and short connections in TCP connection.
Why use TCP persistent connections in Http1.1?
A persistent connection refers to a TCP connection, which means that the TCP connection is reused. In the case of persistent connections, multiple HTTP requests can reuse the same TCP connection, which saves the cost of establishing and disconnecting TCP connections.
In addition, a persistent connection is not permanent. If no HTTP request has been made for the connection for a certain period of time (which can be set in the header), the long connection will be broken.
For a deeper understanding click here
7. Https encryption principle.
There are basically two types of encryption algorithms:
- Symmetric encryption, encryption with the key and decryption with the key is the same, the more representative is AES encryption algorithm;
- In asymmetric encryption, the key used for encryption is called the public key, and the key used for decryption is called the private key. The FREQUENTLY used RSA encryption algorithm is asymmetric encryption.
In addition, there is the Hash encryption algorithm
HASH algorithms: MD5, SHA1, and SHA256
Compared with symmetric encryption, asymmetric encryption is more secure, but it takes longer time to encrypt and decrypt, and the speed is slower.
To learn more about encryption algorithms, click here
HTTPS = HTTP + SSL, HTTPS encryption is done in SSL.
It starts with the CA certificate. A CA certificate is a digital certificate issued by the CA authority. As for the authority of the CA agency, there is no doubt that everyone trusts it. A CA certificate contains the following information:
- Certificate authority and version
- User of the certificate
- Public key of certificate
- Validity period of the certificate
- The digital signature Hash value and signature Hash algorithm of the certificate
- .
How do I verify a CA certificate on a client?
The Hash value in the CA certificate is actually the encrypted value using the private key of the certificate (the private key is not in the CA certificate). After obtaining the certificate, the client uses the public key in the certificate to decrypt the Hash value to obtain Hash -A. Then use the signature Hash algorithm in the certificate to generate a Hash -B. Finally, compare the values of Hash-a and Hash b. If yes, then the certificate is correct and the server can be trusted. If not, the certificate is incorrect and may have been tampered with, and the browser will tell you that an HTTPS connection cannot be established. In addition, it verifies the validity time of the CA certificate and matches the domain name.
SSL handshake setup in HTTPS
Suppose we have client A and server B:
- 1. First of all, client A accesses server B. For example, we open A web page www.baidu.com with A browser. At this time, the browser is client A and baidu’s server is server B. In this case, client A generates A random number 1 and informs server B of the random number 1, the SUPPORTED SSL version number, and the encryption algorithm.
- 2. After server B knows this information, it verifies the encryption algorithm of both parties, and then generates A random number B and returns it to client A together with the certificate issued to it by CA.
- 3. After obtaining the CA certificate, client A verifies the validity of the CA certificate. The verification method is described above. After the verification is passed, the client generates a random number 3, encrypts the random number 3 with the public key in the certificate, and transmits it to the server B.
- 4. Server B obtains the encrypted random number 3, and then uses the private key to decrypt it to get the real random number 3.
- 5. Finally, both client A and server B have random numbers 1, 2 and 3, and then both sides use these three random numbers to generate A conversation key. After the transmission of content is to use the dialogue key to encrypt and decrypt. At this time is the use of symmetric encryption, generally use the AES algorithm.
- 6. Client A notifies server B of the end of client A’s handshake, indicating that the following communication is completed with the dialogue key.
- 7. Server B notifies client A that the following communication will be completed using the dialogue key, and notifies client A that server B’s handshake process is over.
- 8. The SSL handshake ends, and the data communication over the SSL security channel begins. Client A and server B start the data communication using the same conversation key.
Simplified as follows:
- 1. The client establishes an SSL handshake with the server, and the client uses the CA certificate to confirm the identity of the server.
- 2. Pass three random numbers to each other, and then generate a key from this random number;
- 3. Confirm the key with each other, and then shake hands.
- 4, data communication begins, using the same dialogue key for encryption and decryption;
You can see that both symmetric and asymmetric encryption are used in the process of HTTPS encryption principle. It uses the characteristics of high security of asymmetric encryption and the advantages of fast speed and high efficiency of symmetric encryption.
For a deeper understanding click here
How does HTTPS prevent man-in-the-middle attacks?
What is a man-in-the-middle attack?
When a data transfer occurs between a device (PC/ phone) and a web server, the attacker uses his skills and tools to place himself between the two endpoints and intercept the data; Although the two parties in a conversation think they are talking to each other, they are actually talking to the wrongdoer, an attack in the middle.
How many attacks are there?
- 1. Sniffing:
Sniffer or packet sniffing is a technique used to capture packets flowing in and out of a system/network. Packet sniffing on the network is like listening on the phone.
- 2. Packet Injection:
In this technique, an attacker injects malicious packets into regular data. This way the user will not notice the files/malware as they are part of the legitimate traffic flow.
- 3. Session hijacking:
The period between logging in to your bank account and logging out is called a session. These sessions are often targeted by hackers because they contain potentially important information. In most cases, the hacker will lurk in the session and eventually take control of it.
- 4. SSL Stripping:
In AN SSL stripping attack, an attacker spels SSL/TLS connections and the protocol changes from secure HTTPS to insecure HTTP.
How to prevent HTTPS from man-in-the-middle attacks:
See HTTPS Encryption Principles.
9. What are the response codes and what do they mean?
The server receives the request and needs the requester to continue the operation
2** Successful, the operation was successfully received and processed
3** Redirection, which requires further action to complete the request
4** Client error, request contains syntax error or request cannot be completed
5** Server error. An error occurred while the server was processing the request
2, TCP/UDP (⭐⭐⭐)
1. Why does TCP require three handshakes and four waves?
Important flag bit
ACK: TCP specifies that this parameter is valid only when ACK=1. It also specifies that the ACK of all packets sent after a connection is established must be 1
SYN(SYNchronization) : Used to synchronize the sequence number when a connection is established. When SYN=1 and ACK=0, this indicates a connection request packet. If the peer agrees to set up a connection, it should make SYN=1 and ACK=1 in the response packet. Thus, setting SYN to 1 indicates that this is a connection request or a connection receive packet.
FIN (finis) means end, and is used to release a connection. When FIN = 1, it indicates that the data of the sender of the packet segment has been sent and the connection needs to be released.
Three handshakes and four waves
Three handshakes:
First handshake: Establishes a connection. The client sends a connection request packet with the SYN position as 1 and Sequence Number as x. Then, the client enters the SYN_SEND state and waits for confirmation from the server.
Second handshake: The server receives the SYN packet segment. When receiving the SYN packet segment from the client, the server needs to acknowledge this Acknowledgment by setting the Acknowledgment Number to X +1(Sequence Number+1). Set the SYN position to 1 and Sequence Number to y. The server puts all the above information into a packet segment (SYN+ACK packet segment) and sends the packet to the client. At this time, the server enters the SYN_RECV state.
Third handshake: The client receives the SYN+ACK packet from the server. Then set the Acknowledgment Number to Y +1, and send an ACK packet segment to the server. After this packet segment is sent, both the client and server enter the ESTABLISHED state and complete the TCP three-way handshake.
Four waves:
First break up: Host 1 (either the client or the server), set Sequence Number and Acknowledgment Number, and send a FIN packet segment to host 2. Host 1 enters the FIN_WAIT_1 state. This means that host 1 has no data to send to host 2;
Second break up: Host 2 receives the FIN packet segment sent by host 1, and sends an ACK packet segment to host 1. This Acknowledgment Number is the Sequence Number plus 1. Host 1 enters the FIN_WAIT_2 state. Host 2 tells Host 1 that I “agree” to your shutdown request;
Third breakup: Host 2 sends a FIN packet segment to host 1 to close the connection, and host 2 enters the LAST_ACK state.
After receiving the FIN packet segment from host 2, host 1 sends an ACK packet segment to host 2. Then host 1 enters the TIME_WAIT state. After receiving an ACK packet from host 1, host 2 closes the connection. If host 1 does not receive a reply after waiting for 2MSL, it proves that the Server has been properly shut down. Then, host 1 can close the connection.
The purpose of the “three-way handshake” is “to prevent an invalid connection request segment from suddenly being sent back to the server and causing an error.” The main purpose is to prevent the server from waiting and wasting resources. In other words, the first two (first and second) handshakes are performed to ensure that the server receives the information from the client and makes the correct response, and the second and third (second and third) handshakes are performed to ensure that the client receives the information from the server and makes the correct response.
The reason for “four waves” is that TCP is in full-duplex mode. When FIN is received, no data is sent, but data can still be sent.
2, TCP reliable transmission principle implementation (sliding window).
Acknowledgement and retransmission: The receiver acknowledges the packet after receiving it. The sender retransmits the packet if it does not receive acknowledgement within a period of time.
Data verification.
The data is sharded and sorted properly. TCP slices the data. The receiver caches the incoming data in order and reorders the data before submitting it to the application layer.
Process control: When the receiver fails to receive the sent data, it prompts the sender to slow down the sending speed to prevent packet loss.
Congestion control: Reduces data transmission when network congestion occurs.
Click here for details on sliding window, flow control and congestion control
3. What are the differences between Tcp and Udp?
1. Connection-based and connectionless;
2. Requirements on system resources (more TCP, less UDP);
3, UDP program structure is simple;
4. Stream mode and datagram mode;
5, TCP to ensure the correctness of data, UDP may lose packets;
6. TCP guarantees data order, while UDP does not.
4. How to design the UDP layer to ensure the reliability of UDP transmission?
The transport layer cannot guarantee the reliable transmission of data, only through the application layer to achieve. The implementation mode can refer to the TCP reliability transmission mode. Without considering congestion handling, a simple design for reliable UDP is as follows:
- 1. Add seQ/ACK mechanism to ensure that data is sent to the peer end
- 2. Add send and receive buffers, mainly for user timeout retransmission.
- 3. Add the timeout retransmission mechanism.
The specific process is: when the sending end sends data, a random SEQ = X is generated, and then seQ is allocated to each piece according to the data size. After the data reaches the receiver, the receiver puts it in the cache and sends an ACK =x packet, indicating that the receiver has received the data. After receiving an ACK packet, the sender deletes the data corresponding to the buffer. When the time is up, the scheduled task checks whether the data needs to be retransmitted.
At present, there are the following open source programs using UDP to achieve reliable data transmission. RUDP, RTP, UDT:
1. Reliable User Datagram Protocol (RUDP)
RUDP provides a set of data service quality enhancement mechanisms, such as congestion control improvement, resend mechanism and dilution server algorithm.
2. Real Time Protocol (RTP)
RTP provides end-to-end transmission services for data with real-time characteristics, such as interactive video and audio or analog data under multicast or unicast network services.
3. Udt-based Data Transfer Protocol (UDT)
The primary purpose of UDT is to support massive data transmission over high speed wide area networks.
More information about RUDP, RTP, and UDT can be found here
3. Other Important Network Concepts (⭐⭐)
1, socket disconnection reconnection how to achieve, and how to achieve the heartbeat mechanism?
The socket concept
Socket (socket) is the cornerstone of communication, is the basic operation unit of network communication that supports TCP/IP protocol. It is an abstract representation of an endpoint in the process of network communication, including five kinds of information necessary for network communication: protocol used for connection, IP address of the local host, protocol port of the local process, IP address of the remote host, and protocol port of the remote process.
To distinguish between different application processes and connections, many computer operating systems provide Socket interfaces for applications to interact with the TCP/IP protocol. The layer should be able to distinguish the communication from different application processes or network connections through Socket interfaces with the transport layer to realize the concurrent service of data transmission.
Establishing a Socket connection
Establishing a Socket connection requires at least one pair of sockets, one running on the client side, called ClientSocket, and the other running on the server side, called ServerSocket.
Connecting between sockets is a three-step process: server listening, client requesting, and connection confirmation.
- Server listening: The server socket does not locate the specific client socket, but is in the waiting state, monitoring the network status in real time, waiting for the client to connect request.
- Client request: a request from a socket on the client to connect to a socket on the server. To do this, the client socket must first describe the server socket it is connecting to, specify the address and port number of the server-side socket, and then make a connection request to the server socket.
Connection acknowledgement: When the server socket hears or receives a connection request from the client socket, it responds to the request from the client socket by creating a new thread and sending the description of the server socket to the client. Once the client acknowledges the description, the connection is established. The server socket continues to listen and continues to receive connection requests from other client sockets.
The SOCKET connection is connected to the TCP connection
When you create a Socket connection, you can specify the transport layer protocol to be used. A Socket can support different transport layer protocols (TCP or UDP). If the TCP protocol is used for a connection, the Socket connection is a TCP connection.
The Socket connection connects to the HTTP connection
Since a Socket connection is usually a TCP connection, once the Socket connection is established, both parties can start sending data to each other until the connection is disconnected. But in the practical application of networks, communications between the client to the server often need through multiple intermediate nodes, such as routers, gateways, firewalls, etc., most of the default firewall will be shut down for a long time in the inactive state of the connection to the Socket connection disconnected, so you need to told network by polling, the connection is active.
The HTTP connection uses the “request-response” mode, which not only requires the connection to be established before the request, but also requires the client to send a request to the server before the server can reply data.
In many cases, the server needs to actively push data to the client to keep the real-time data synchronization between the client and the server. At this point, if both sides establish a Socket connection, the server can directly send the data to the client; If both sides is HTTP connections, the server needs to wait until the client sends a request to the data back to the client, therefore, the client sends a connection request to the server regularly can not only keep online, is also in the “ask” if there is a new data server, if there is to transmit the data to the client. Transmission Control Protocol (TCP)
Implementation of socket disconnection
If the connection is disconnected, the client sends a FIN packet to the server. The server knows that the connection is disconnected only after receiving the FIN packet. However, the client cannot send fin packets to the server when the network is disconnected, so the server cannot detect that the client has a short line. To alleviate this problem, the server needs to have a heartbeat logic, that is, when the server detects how long it has not sent any data from a client, it considers that the client is disconnected. This requires the client to periodically send heartbeat data to the server to maintain the connection.
Implementation of heartbeat mechanism
Most application layer protocols have a HeartBeat mechanism, usually a client sends a packet to the server at short intervals to notify the server that it is still online. And transmit any data that may be necessary. The typical protocol for using heartbeat packets is IM, such as QQ/MSN/ Feiteng, etc
1. In THE TCP mechanism, there is a heartbeat packet mechanism, which is the TCP option: SO_KEEPALIVE. The default value is 2 hours. But it can not check the machine power, pull out the network cable, firewall these disconnection. And the logical layer may not be so easy to deal with broken lines. In general, if only for survival or can be used. By using TCP’s KeepAlive mechanism (modifying that time parameter), it is possible to make connections emit ACK packets at short intervals to reduce the risk of being kicked, at the cost of additional network and CPU burdens.
2. Implementation of application layer heartbeat mechanism
2. Functions and principles of cookies and sessions.
- Session is a data structure stored on the server to track the status of users. This data can be stored in clusters, databases, and files.
- Cookie is a mechanism for the client to save user information. It is used to record some user information and also a way to implement Session.
The Session:
Since HTTP is a stateless protocol, when the server needs to record the state of the user, it needs to use some mechanism to identify the specific user. This mechanism is called Session. In a typical scenario like the shopping cart, when you click the order button, because HTTP is stateless, you don’t know which user is doing it, so the server has to create a specific Session for that particular user, identify that user, and track that user so that you know how many books are in the shopping cart. This Session is stored on the server and has a unique identifier. There are many ways to save a Session on the server, including memory, database, and file. In large websites, there is usually a special Session server cluster, which is used to store user sessions. In this case, Session information is stored in memory.
A Session in the Web context refers to the amount of time a user spends browsing a site, from the time he enters the site to the time he closes the browser. Therefore, from the above definition, we can see that Session is actually a specific time concept.
When the client accesses the server, the server sets the Session as required, saves the Session information on the server, and passes the Session ID to the client browser.
The browser saves this SessionId in memory, which we call a Cookie with no expiration time. When the browser closes, the Cookie is cleared and does not exist in the user’s Cookie temporary file.
In the future, the browser will add this parameter value to each request, and the server will use this SessionId to retrieve the client data.
If the client browser shuts down unexpectedly and the Session data is not released immediately, the data will still exist. As long as we know the Session ID, we can continue to request the Session information because the Session still exists in the background. We can set a Session timeout period. If there is no client request after the specified period, the server will clear the Session information corresponding to the Session ID.
Cookie
Cookies are generated by the server and sent to the user-agent (generally a Web browser). The browser will save the key/value of the Cookie to a text file in a directory and send the Cookie to the server when requesting the same website next time (provided that the browser is set to enable Cookie). The Cookie name and value can be defined by the server side development, or the Sessionid can be written directly to the JSP, so the server can know if the user is a valid user and needs to log in again.
3. Contents of IP packets.
Version: Indicates the IP protocol version. The current IP protocol version is 4, and the next generation IP protocol version is 6.
Header length: indicates the length of the IP header. Sum of the length of the fixed part (20 bytes) and the length of the variable part. A total of 4. The maximum length of an IP header is 1111, that is, 15 in decimal notation. The maximum length of an IP header is 15 32bits (4 bytes). That is, the maximum length of an IP header is 60 bytes (15 x 4).
Service Type: Type Of Service.
Total Length: indicates the total length of IP packets. The sum of the length of the header and the length of the data section.
Identifier: Uniquely identifies each score report sent by the host. In general, the value is increased by one each time a message is sent. When the length of an IP packet exceeds the maximum transmission unit (MTU) of the transmission network, the IP packet must be fragmented. The value of the IDENTITY field is copied to all the identity fields of the data fragments. When the fragments reach the final destination, they can be reconstructed into the original data according to the content of the identity field.
Logo: a total of 3 digits. R, DF and MF. Currently, only the last two bits are valid. The DF bits: 1 indicates that the DF bits are not fragmented, and 0 indicates that the DF bits are fragmented. MF: A value of 1 means “more slices” and a value of 0 means this is the last slice.
Slice displacement: the offset of the fragment relative to the first digit in the original data packet. (Multiply by 8)
TTL: indicates the maximum number of routers through which IP packets can pass. Each time it passes through a router, the TTL decreases by 1. When the TTL is 0, the router dismisses the datagram. The TTL field is an 8 bit field initially set by the sender. The recommended initial value is specified by the allocation number RFC, currently 64. The TTL is often set to the maximum value 255 when sending an ICMP echo response.
Protocol: Indicates which protocol is used for the data carried by IP packets, so that the IP layer of the destination host can know which process to deliver the datagram to (different protocols have different processes to handle it). The protocol number is similar to the port number. The TCP protocol number is 6, and the UDP protocol number is 17. The ICMP protocol number is 1, and the IGMP protocol number is 2.
Header checksum: Calculates the checksum of the IP header to check the integrity of the IP header.
Source IP address: Identifies the source device of the IP datagram.
Destination IP Address: Indicates the destination IP address of an IP datagram.
Finally, we have the variable part and the data part.
Iv. Common Network process mechanism (⭐⭐)
1.What happens when the browser enters the address and returns the result?
In general, it can be divided into the following processes:
1, DNS resolution, in addition to DNSy optimization (DNS cache, DNS load balancing)
2. TCP connection
3. Send an HTTP request
4. The server processes the request and returns an HTTP packet
5. The browser parses the rendered page
6. The connection is complete
The nature of the Web front end
To present information to users quickly and in a friendly way and be able to interact with them.
How to load resources as quickly as possible (network optimization)?
The answer is that resources that can not be loaded from the network will not be loaded from the network, and when we use caching properly and put resources on the browser side, this is the fastest way. If resources must be loaded from the network, consider shortening the connection time, i.e., the DNS optimization part; Reduce the response content size, that is, compress the content. On the other hand, if the number of resources loaded is relatively small, it can also respond to users quickly.
Operating system (⭐⭐⭐)
1.How does the operating system manage memory?
2,Process scheduling.
3,What’s the difference between a Linux process and a thread.
The main difference between processes and threads is that they are different ways of managing operating system resources. Processes have separate address Spaces, and when a process crashes, it does not affect other processes in protected mode, while threads are just different execution paths within a process. Threads have their own stack and local variables, but there is no separate address space between threads, a process is dead equals to all threads die, so multi-process programs are more robust than multithreaded programs, but in the process switch, more resources, less efficiency. However, for some concurrent operations that require simultaneous operations and share some variables, only threads can be used, not processes.
-
In short, a program has at least one process, and a process has at least one thread.
-
The partition scale of threads is smaller than that of processes, which makes the concurrency of multithreaded programs high.
-
In addition, the process has an independent memory unit during execution, while multiple threads share the memory, which greatly improves the efficiency of the program.
-
Threads are different from processes during execution. Each individual thread has an entry point for the program to run, a sequence of sequential execution, and an exit point for the program. However, threads cannot be executed independently, and must be dependent on the application program, which provides multiple thread execution control.
-
From a logical point of view, multithreading means that multiple parts of an application can be executed simultaneously. However, the operating system does not treat multiple threads as multiple independent applications to achieve process scheduling and management and resource allocation. This is the important difference between processes and threads.
4. Can you explain Linux soft links and hard links?
Linux links come in two types: Hard links and Symbolic links. By default, the ln command generates a hard link.
Hard to connect
A hard link is a connection through an inode. On the Linux file system, files stored on disk partitions, regardless of their type, are assigned a number, called an Inode Index. In Linux, it is possible for multiple filenames to point to the same inode. Usually this connection is a hard connection. The purpose of a hard link is to allow a file to have multiple valid pathnames, so that users can establish a hard link to important files to prevent “accidental deletion” function. The reason for this is explained above, because there is more than one join to the inode of the directory. Deleting only one connection does not affect the inode itself and other connections. Only after the last connection is deleted, the data blocks of files and directory connections are released. In other words, the actual condition for a file to be deleted is that all hard-linked files associated with it are deleted.
Soft connection
The other type of Link is called a Symbolic Link, also known as a soft Link. Soft link files have windows-like shortcuts. It’s actually a special file. In a symbolic link, the file is actually a text file that contains the location information of another file.
5. Android rights management. Why can android APP be used if you register permissions in the list, but not vice versa?
This question examines the role of Permissions management in Android’s security architecture.
Android is a permissions separated operating system, where each application has its own unique system identity (Linux user ID and group ID). Each part of the system is also separated into different identifiers. Linux uses this to separate different applications and applications from the system.
Other, more detailed security features are provided through the “permissions” mechanism, which restricts the specific operations that specific processes can perform and authorizes temporary access to specific segments of data based on URI permissions.
The central design point of The Android security architecture is that by default no application has the authority to perform any action that adversely affects another application, the operating system, or the user. This includes reading or writing a user’s private data (such as contacts or E-mail), reading or writing files from other applications, performing network access, keeping the device awake, and so on.
Because every Android application runs in a process sandbox, the application must explicitly share resources and data. They do so by declaring what permissions are required to obtain additional functionality not provided by the basic sandbox. Applications declare the permissions they require statically, and Android prompts the user to agree.
Database (⭐)
1, the four characteristics of the database, the isolation level of the database?
A Transaction is the basic unit of concurrency control. A transaction is a sequence of operations, all of which are performed or none of which are performed. It is an indivisible unit of work. For example, a bank transfer that takes money from one account and increases money from another account is either done or done nothing. So, think of them as a transaction. Transaction is the unit of database to maintain data consistency. At the end of each transaction, data consistency can be maintained. Transactions have the following four basic characteristics:
Four characteristics of database:
(1) Atomicity
Atomicity means that all operations contained in a transaction either succeed or fail to roll back.
(2) Consistency
A transaction must be in a consistent state both before and after execution.
(3) Isolation
Isolation means that when multiple users concurrently access the database, such as the operation of the same table, the database for each user to open the transaction, cannot be disrupted by other transaction operations, multiple concurrent transactions should be isolated from each other.
(4) Durability
Persistence means that once a transaction is committed, changes to the data in the database are permanent.
Isolation levels for the database:
1) Serializable: Dirty read, non-repeatable read and fantasy read can be avoided.
2) Repeatable read: can avoid dirty read and non-repeatable read.
3) Read committed: avoid dirty reads.
4) Read uncommitted: The lowest level, which is not guaranteed in any case.
2. What are the three normal forms often used in database design?
1) First normal form 1NF(Atomicity of domains)
If all the field values in a database table are non-factorable atomic values, the database table satisfies the first normal form
2) Second normal form 2NF(all columns in a table except the primary key depend entirely on the primary key)
The second normal form is based on the first normal form. The second normal form has two important points :(1) the table must have a primary key; (2) Other non-primary attributes must depend entirely on the primary key, not only on a portion of the primary key (mainly for the associative primary key).
3) third normal form 3NF (all columns in the table except primary keys are completely direct dependencies, cannot be passed dependencies)
A non-primary key column A depends on A non-primary key column B, and A non-primary key column B depends on A primary key. 2NF: Whether a non-primary key column depends entirely on the primary key or on a part of the primary key; 3NF: Whether non-primary key columns depend directly on primary keys or non-primary key columns.
Data Structures and Algorithms (⭐⭐⭐)
For algorithmic interview preparation, there is no doubt that the best effect is to brush “Sword Point Offer” + LeetCode. Brush “Sword Point Offer” is to establish a comprehensive algorithminterview thinking, to lay a solid foundation, brush LeetCode is to continue to strengthen and broaden our own algorithmthinking. These two cS-Notes have been implemented perfectly, I recommend that you brush “Sword Point Offer”, and then brush at least 100 LeetCode questions.