preface

Between their own network knowledge rotten in a complete mess, so ready to write the relevant network article, but consider all written in one is too long, so separate write, I hope you can look carefully, the best can point out my mistakes, let me also can correct.

1. Explain the whole network architecture:

Android Skill Tree – Network Summary (1) network Architecture

TCP, UDP,socket,websocket, HTTP, HTTPS. What is webService? It is similar to websocket. Socket and Websocket are similar in terms of session,token and cookie.

Android Skill Tree – Network Summary (2) TCP/UDP

Android Skill Tree – Web Summary (3) HTTP/HTTPS

Android skill tree – network summary (4) of the socket/websocket/webservice

Cookie /session/token (to be written)

3. Source code analysis of relevant third party frameworks, after all, okHTTP and Retrofit source code is a must for interviewing large companies now.

Android Skill Tree – Network summary (6) OkHttp super super super super super super super super super super detail analysis

Android Skill Tree – Network Summary (7) Retrofit source code detailed parsing

The body of the

When you interview people, ask them the difference between HTTP and HTTPS, many people will answer: HTTPS is more secure, but ask them specific HTTP related basis, why HTTPS is more secure, many people will not answer. So this time, let’s look at the specific knowledge points.

1.Http request packets

The content we send to the server looks like it’s just passing a few parameter values to them, but it’s actually packaged into a package and sent to them.

Let’s start with the request package we normally send to the server:

There are four main pieces:

  1. The request line
  2. The request header
  3. A blank line
  4. The request data

For those of you who don’t know, let’s go one by one:

1.1 request line

1.1.1 Request Line – Request method

The request method is nothing more than:

Of course, many interfaces are not strictly Restful:

Operations before Restful: http://127.0.0.1/user/save http://127.0.0.1/user/query/1 GET according to the user id of the user data POST new users POST at http://127.0.0.1/user/update Modify the user information http://127.0.0.1/user/delete GET/POST to delete user information RESTful usage: http://127.0.0.1/user/1 GET Queries user data based on the user ID http://127.0.0.1/user POST Adds a user http://127.0.0.1/user PUT Modifies user information http://127.0.0.1/user DELETE Deletes user informationCopy the code

Therefore, more and more people’s information is submitted to the background and more and more people still use GET and POST.

GET and POST:

GET is not secure. It is in plain text. POST is more secure. In fact, these are more relative to the previous era of web browser, because before get request we can directly see the relevant information in the browser input field; And GET requests are limited because browsers limit the length of urls.

Conclusion:

  • Android development is a direct mobile app to send requests to the server, you can not see the corresponding URL, and if you do not use HTTPS, get and POST are in clear text, capturing some packets can also see the information.
  • And since it’s not a browser, there’s no limit on the word length of the URL.
  • URLEncoder. Encode (params, “GBK “);

So in theory there’s not a lot of difference between getting and POST when you’re developing on mobile, but it’s a good idea to be more formal, because we usually use GET to get information directly, and post to submit information to the server.

1.1.2 Request Line – URL

The format of an HTTP URL (a URL is a special type of URI that contains enough information to find a resource) is http://host[” : “port][abs_path]

HTTP: uses HTTP to locate network resources. Host indicates a valid Internet host domain name or IP address. Port Specifies a port number. If the port number is empty, the default port 80 is used. Abs_path Specifies the URI of the requested resource;

If the ABS_path is not given in the URL, it must be given in the form of a “/” when it is used as the request URI, which the working browser usually does automatically for us. For example: 1, the input: www.guet.edu.cn browser automatically converted into: HTTP: www.guet.edu.cn/ 2, 192.168.0.116:8080 / index. The JSP

This is simply the URL of an interface that we normally interact with the server. I won’t go into that.

1.1.3 Request Line – Protocol Version

The HTTP protocol we mainly have three kinds: HTTP / 1.0, HTTP / 1.1, HTTP / 2.0

HTTP/1.0 differs from HTTP/1.1:

  • Long connections: HTTP 1.0 requires the keep-alive parameter to tell the server to establish a long connection, whereas HTTP1.1 supports long connections by default. Multiple HTTP requests and responses can be sent in the same TCP connection.
  • Bandwidth saving: HTTP 1.1 supports sending only header information (without any body information)
  • Multiple requests & responses can occur simultaneously and overlap
  • Introduction of more request and response headers (e.g., HTTP1.0 without host fields related to authentication, state management, and Cache caching)

HTTP/1.1 differs from HTTP/2.0:

  • Multiplexing: HTTP2.0 uses a multiplexing technique to concurrently process multiple requests for the same connection, and the number of concurrent requests is orders of magnitude larger than HTTP1.1.
  • Data compression: HTTP1.1 does not support compression of header data. HTTP2.0 uses the HPACK algorithm to compress header data, so that the data volume is smaller, faster transmission over the network.
  • Server push: When we request data from a Web server that supports HTTP2.0, the server will incidentally push some resources to the client, so that the client will not create a connection to send a request to the server. This is a great way to load static resources.

1.2 Request Headers

We can see that the request header consists of columns of key-value pairs, such as:

Packet Body object Type Content-Type: text/ HTML Field value A single HTTP header field can have multiple values, such as keep-alive: timeout=15, Max =100Copy the code

This may not be the case if the HTTP header field is repeated depending on the browser. Some browsers give priority to the first header field, while others give priority to the last header field.

1.2.1 Request Headers – Common header field

Header used by both request and response packets.

1.2.2 Request Header – Request header Field

This command is used when the client sends a request packet to the server, which provides additional information about the request, client information, and priority of the response

1.2.3 Request Headers – Entity header Field

The header used for the entity portion of request and response messages. Added entity-related information such as when the resource content was updated.

1.3 a blank line

The function of separating the header from the request body, indicating that what follows is the request body.

1.4 Requesting Data

The optional part, such as GET request, can have no request data. The request data is the content that we actively fill in and pass. This request data has the following formats:

1.5 Summary of Request Packets

2. Respond to the packet

We know that on a regular basis we get messages from the back end:

{
    "success":true."msg":"xxxx"."data": {"key1":value1,
        "key2":value2}} (' 'code' 'is used to return the value of' 'success', and then mobile to determine if it is 200.)Copy the code

Similarly, it is also packaged into a packet and sent to us, so let’s look at the structure of the corresponding packet:

We can see that the response header is similar to the request header, and the response body is the same as the request body, with the difference between the status line and the request line. Let’s look at them one by one

2.1 the status line

This estimate is widely known. I won’t go into the details. PS: I was asked in an interview what 302 is and what 301,303 is different. Very impressive.

2.2 Response Header

The request header field in the middle is replaced by the response header field:

So let’s focus on the response header field:

2.3 a blank line

Blank line of the request message

2.4 Response Text

With the request body, also the same three formats.

2.5 Summary of Request Packets

3. HTTPS security reasons

We know THAT HTTPS is secure, but where exactly is it?

HTTPS = HTTP + SSL/TLS

  1. Asymmetric encryption
  2. Symmetric encryption
  3. Hash algorithm

If you look at the three nouns above, I think 99 percent of you will know that they are used in HTTPS. How do you use them?

  1. We know we want to protect our data security, must want to encrypt data, are generally use symmetric encryption, and encrypted to each other, but two people all know that the key in advance, if you don’t know in advance, will put the key in some way, that there is a problem, because the time may be being stolen, robbed after encryption as clear text.
  2. The problem then becomes how to safely give the symmetric encryption key to the other party, so asymmetric encryption is used, the server takes the private key, and then gives the sender the public key, and then the sender takes the public key and encrypts the symmetric encryption key, so that only the server with the private key can unlock it. You can then use symmetric keys to encrypt data interactions.
  3. The question becomes how can I secure the asymmetric encryption public key to the sender in advance without someone secretly swapping the public key in the middle? In this case, a CA certificate (which is equivalent to a public key) is required.

Some people ask why asymmetric encryption is not used to encrypt data directly, because asymmetric encryption decrypts data slower than symmetric encryption.

A server that uses HTTPS must have a digital certificate (CA certificate), which can be created by yourself or applied for from an organization. The difference is that your certificate needs to be verified by the client before you can continue to access it, while certificates applied by trusted companies do not pop up a prompt page (StartSSL is a good choice, with a one-year free service). The certificate is a pair of public and private keys.

Let’s do a more complete process:

  1. The client initiates an HTTPS request

  2. Server configuration: A server that uses HTTPS must have a digital certificate, which can be made by itself or a CA certificate. The difference is that the client can continue to access the self-issued certificate only after the certificate is authenticated by the client. If the CA certificate is used, no prompt page is displayed. The certificate is a pair of public and private keys. The public key is encrypted for others, and the private key is decrypted for yourself.

  3. Transfer certificate: This certificate is actually the public key, but contains a lot of information, such as certificate authority, expiration date, etc.

  4. Client certificate parsing: This part of the work is completed by TLS on the client. First, it verifies whether the public key is valid, such as the issuing authority and expiration time. If an exception is found, a warning box is displayed indicating that the certificate has a problem. If the certificate is fine, a random value is generated, and the random value is encrypted with the certificate.

  5. Transmit encrypted information: This part transmits the random value encrypted with the certificate. The purpose is to let the server get the random value, and the communication between the client and the server can be encrypted and decrypted by this random value.

  6. Service segment decryption information: after decrypting with the private key, the server gets the random value (private key) from the client, and then encrypts the content symmetrically through this value. Symmetric encryption is the mixing of information and the private key through some algorithm, so that unless you know the private key, you can’t get the content, and both the client and the server know the private key, so as long as the encryption algorithm is strong enough, the private key is complex enough, the data is secure enough.

  7. Transfer encrypted information: This part of the information is the service segment encrypted with the private key, can be restored on the client.

  8. Client decryption message: The client decrypts the message sent by the service segment with the previously generated private key, and then obtains the decrypted content.

4. The difference between HTTP and HTTPS

Conclusion:

emmmm……. Spray lightly. If you have a mistake, please leave a message and I can modify it. The part of the article illustration is taken from the following reference article.

Reference article:

HTTP shaking hands with HTTPS

HTTP header (1)

Computer networking: this is a comprehensive and detailed explanation of HTTP knowledge

A minute to understand HTTPS








My blog is handling synchronization to tencent cloud + community, invite everyone to come together: cloud.tencent.com/developer/s…