NSOperation, NSOperationQueue, and NSThread+ Runloop implement resident threads and locks

  • The advantages of NSOperationQueue
  • NSOperation and NSOperationQueue
  • NSThread+runloop implements resident threads
  • Spin locks and mutexes

Advantages of NSOperationQueue

NSOperation and NSOperationQueue are a set of multi-threaded solutions provided by Apple. In fact, NSOperation and NSOperationQueue are based on a higher level of encapsulation of GCD, fully object-oriented. But it is easier to use than GCD and the code is more readable.

  • 1. Task dependencies can be added to facilitate the control of execution sequence
  • 2. You can set the priority of the operation
  • 3, task execution status control: isReady, isExecuting, isFinished, isCancelled

If you just override the main method of NSOperation, and the underlying control changes the execution and completion state of the task, and the exit of the task if you override the start method of NSOperation, Control the task status by yourself The system removes NSOperation in isFinished==YES by using KVO

  • 4. You can set the maximum concurrency

NSOperation and NSOperationQueue

  • Operation:

The meaning of performing an operation, in other words, is the piece of code that you execute in the thread. In GCD they are placed in blocks. In NSOperation, use NSOperation subclasses NSInvocationOperation, NSBlockOperation, or custom subclasses to encapsulate the operation.

  • Operation Queues:

The queue here refers to the operation queue, that is, the queue used to store the operation. This is different from the SCHEDULING queue FIFO (first in, first out) principle in GCD. NSOperationQueue For operations added to the queue, the ready state is first entered (the ready state depends on the dependencies between the operations), and then the start order (not the end order) of the operations entering the ready state is determined by the relative priority of the operations (the priority is an attribute of the operation object itself). Operation queue by setting the maximum number of concurrent operation (maxConcurrentOperationCount) to control the concurrency, serial. NSOperationQueue provides us with two different types of queues: a main queue and a custom queue. The main queue runs on top of the main thread, while the custom queue executes in the background.

IOS Multithreading:”NSOperation,NSOperationAn exhaustive summary of Queue – a short book

NSThread+ Runloop implements resident thread

One of the most common development scenarios for NSThreads is to implement resident threads.

  • Since each subthread will consume CPU, in the case of frequent use of subthreads, frequent subthreads will consume a lot of CPU, and the creation of a thread is completed after the task is released, can not be reused, so how to create a thread so that it can work again? That is, create a resident thread.

First, since resident threads are resident, we can implement a singleton using GCD to hold nsThreads

+ (NSThread *)shareThread {

    static NSThread *shareThread = nil;

    static dispatch_once_t oncePredicate;

    dispatch_once(&oncePredicate, ^{

        shareThread = [[NSThread alloc] initWithTarget:self selector:@selector(threadTest) object:nil];

        [shareThread setName:@"threadTest"];

        [shareThread start];
    });

    return shareThread;
}

Copy the code

So the thread created will not be destroyed?

[self performSelector:@selector(test) onThread:[ViewController shareThread] withObject:nil waitUntilDone:NO];

- (void)test
{
    NSLog(@"test:%@", [NSThread currentThread]);
}

Copy the code

Does not print, indicating that the test method was not called. You can use runloop to make the thread resident

+ (NSThread *)shareThread { static NSThread *shareThread = nil; static dispatch_once_t oncePredicate; dispatch_once(&oncePredicate, ^{ shareThread = [[NSThread alloc] initWithTarget:self selector:@selector(threadTest2) object:nil]; [shareThread setName:@"threadTest"]; [shareThread start]; }); return shareThread; } + (void)threadTest { @autoreleasepool { NSRunLoop *runLoop = [NSRunLoop currentRunLoop]; [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode]; [runLoop run]; }}Copy the code

And then you call performSelector and you print.

Spin locks and mutexes

The spin lock.

Is a lock used to protect a shared resource shared by multiple threads. Unlike mutex, a spin lock iterates to check whether the lock is available in the form of a busy waiting while trying to acquire it. When the task of the previous thread is not finished (locked), then the next thread will wait (not sleep), when the task of the previous thread is finished, the next thread will execute immediately. In a multi-CPU environment, using a spin lock instead of a general mutex can often improve performance for programs with short locks.

Exclusive locks:

When the previous thread’s task does not finish (it is locked), the next thread will go to sleep and wait for the task to finish. When the previous thread’s task finishes, the next thread will automatically wake up and execute the task.

Conclusion:

Spin-locks are busy, etc. : When accessing a locked resource, the caller thread does not go to sleep, but loops around until the locked resource releases the lock. The mutex will sleep: Sleep means that when accessing the locked resource, the caller thread will sleep and the CPU can schedule other threads to work. Until the locked resource releases the lock. The dormant thread is awakened.

The advantages and disadvantages:

The advantage of a spin lock is that because it does not cause the caller to sleep, there are no time-consuming operations such as thread scheduling, CPU time slits, and so on. So spin locks are much more efficient than mutex locks if they can be acquired in a short amount of time. The disadvantage is that a spin-lock consumes the CPU all the time. It is running without the lock, spinning, so it consumes the CPU. If the lock cannot be acquired in a short time, it will definitely reduce the CPU efficiency. Spin locks do not implement recursive calls.

Spin-lock: atomic, OSSpinLock, dispatch_semaphore_t
Mutex: pthread_mutex, @synchronized, NSLock, NSConditionLock, NSCondition, NSRecursiveLock

10. Data structure of RunLoop, implementation mechanism of RunLoop, Mode of RunLoop, RunLoop and NSTimer and thread

RunLoop concept
The data structure of RunLoop
The RunLoop Mode
Implementation mechanism of RunLoop
RunLoop and NSTimer
RunLoop and thread

1. RunLoop concept

RunLoop is maintained internallyEvent LoopCome to the rightEvent/message managementAn object of.

1. When there is no message processing, the hibernation has avoided resource occupation, and the user mode is switched to the kernel mode (CPU-kernel mode and user mode). 2

Why doesn’t main exit?
int main(int argc, char * argv[]) { @autoreleasepool { return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); }}Copy the code

UIApplicationMain internally turns on a RunLoop for the main thread and executes an infinite loop (not a simple for or while loop).

Int main(int argc, char * argv[]) {BOOL running = YES; Do {// Perform various tasks and handle various events //...... } while (running); return 0; }Copy the code

The UIApplicationMain function never returns, but is constantly receiving processing messages and waiting for sleep, so the program is kept running after running.

2. Data structure of RunLoop

NSRunLoop(Foundation) is a wrapper around CFRunLoop(CoreFoundation) and provides an object-oriented API for RunLoop.

CFRunLoopMode: running mode CFRunLoopSource: input source/event source CFRunLoopTimer: timing source CFRunLoopObserver: observer

1, CFRunLoop

By pthread(thread object, Note RunLoop and thread are one-to-one corresponding), currentMode(current running mode), MODES (collection of multiple running modes), commonModes(collection of mode name strings), and commonModelItems(Observer,Timer,Sourc) E set)

2, CFRunLoopMode

Consists of name, source0, source1, observers, and timers

3, CFRunLoopSource

There are two types: source0 and source1

  • source0: Non-port-based, i.e. user-triggered events. You need to manually wake up the thread to switch the current thread from kernel mode to user mode
  • source1: port-based, contains a mach_port and a callback that listens for the system port and messages sent through the kernel and other threads, can proactively wake up the RunLoop and receive and distribute system events. Have the ability to wake up threads
4, CFRunLoopTimer

Time-based triggers, that’s basically NSTimer. Wake up the RunLoop at a preset point in time to perform the callback. Because it is based on RunLoop, it is not real-time (i.e., NSTimer is inaccurate). Because RunLoop is only responsible for distributing messages from the source. If the thread is currently processing heavy tasks, it may cause the Timer to delay this time, or execute one less time.

5, CFRunLoopObserver

Listen for the following point in time :CFRunLoopActivity

  • kCFRunLoopEntryRunLoop is ready to start
  • kCFRunLoopBeforeTimersRunLoop will handle some timer-related events
  • kCFRunLoopBeforeSourcesRunLoop will handle some Source events
  • kCFRunLoopBeforeWaitingRunLoop is about to go into hibernation, switching from user mode to kernel mode
  • kCFRunLoopAfterWaitingRunLoop is awakened, that is, after switching from kernel mode to user mode
  • kCFRunLoopExitRunLoop exit
  • kCFRunLoopAllActivitiesListen for all states
6. Relationships between data structures

Threads correspond to runloops one to one. RunLoop and Mode are one-to-many, and Mode is one-to-many with source, timer, and observer

3. Mode of RunLoop

The first thing to know about Mode is that a RunLoop object may contain more than one Mode, and only one Mode(CurrentMode) can be specified each time RunLoop’s main function is called. To switch Mode, you need to specify a new Mode. The main purpose is to separate different Source, Timer, Observer, so that they do not affect each other.

When a RunLoop is running on Mode1, it is not acceptable to process Source, Timer, or Observer events on Mode2 or Mode3

There are five types of CFRunLoopMode:

  • KCFRunLoopDefaultMode: The default mode in which the main thread runs

  • UITrackingRunLoopMode: Track user interaction events (used for ScrollView tracking touch sliding, to ensure that the interface is not affected by other modes)

  • UIInitializationRunLoopMode: in the first to enter the first Mode when just start the App, start after the completion of the will no longer be used

  • GSEventReceiveRunLoopMode: accept system internal event, is usually not used

  • KCFRunLoopCommonModes: pseudo-modes, not a real Mode of operation, but a solution for synchronizing Source/Timer/Observer to multiple modes

Iv. Implementation mechanism of RunLoop

This picture is widely circulated on the Internet. The core thing to do with RunLoop is to make sure that threads sleep when there are no messages and wake up when there are messages to improve performance. The RunLoop mechanism relies on the kernel (Mach in Darwin, the core component of Apple’s operating system).

RunLoop receives and sends messages through the mach_msg() function. Essentially, it calls the function mach_msg_trap(), which is a system call that triggers a kernel state switch. Calling mach_msg_trap() in user mode switches to kernel mode; The kernel implementation of the mach_msg() function in kernel mode does the actual work. That is, based on the source1 of the port, listen to the port, the port will trigger a message callback; For source0, manually mark it as pending and manually wake up RunLoop

The Mach message sending mechanism has the following logic: 1. Notifying observers that RunLoop is about to start. 2. Notifies the observer that the Timer event is about to be processed. Inform observers that the Source0 event is about to be processed. Process the source0 event. 5. If the port-based source (Source1) is ready and in the waiting state, go to Step 9. 6. Notify the observer that the thread is going to sleep. 7. Put the thread into hibernation state, switch from user mode to kernel mode, and wake up the thread until any of the following events occur.

  • An event based on port Source1 (source0).
  • A Timer is up.
  • The timeout of the RunLoop itself has expired.
  • Being awakened manually by another caller.

Inform the observer that the thread will be awakened. 9. Handle events received upon awakening.

  • If the user-defined timer starts, handle the timer event and restart RunLoop. Go to Step 2.
  • If the input source is started, deliver the appropriate message.
  • If RunLoop is shown to be awake and has not timed out, restart RunLoop. Go to Step 2

10. Notify the observer that the RunLoop is complete.

RunLoop and NSTimer

A common question: Will the timer still work when you slide the tableView? By default, RunLoop runs in kCFRunLoopDefaultMode, and when sliding the tableView, RunLoop switches to UITrackingRunLoopMode, and Timer is in kCFRunLoopDefaultMode, You cannot accept the event for processing the Timer. How to solve this problem? Adding a Timer to UITrackingRunLoopMode does not solve the problem because it will not accept Timer events by default. So we need to add the Timer to both UITrackingRunLoopMode and kCFRunLoopDefaultMode. So how do you add a timer to multiple modes simultaneously? So NSRunLoopCommonModes

[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];

Copy the code

The Timer is added to multiple modes, so that even if the RunLoop is switched from kCFRunLoopDefaultMode to UITrackingRunLoopMode, the Timer event will not be affected

RunLoop and thread

  • Threads and runloops correspond one to one, and the mapping is stored in a global Dictionary
  • Self-created threads do not have RunLoop enabled by default
How to create a resident thread?

Start a RunLoop for the current thread (the first call to [NSRunLoop currentRunLoop] actually creates a RunLoop) Add a Port/Source to the current RunLoop to maintain the RunLoop event loop (if there is no item in the mode of the RunLoop, the RunLoop will exit)

   @autoreleasepool {

        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];

        [[NSRunLoop currentRunLoop] addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];

        [runLoop run];

    }

Copy the code
2. Output the execution order of the code below
 NSLog(@"1");

dispatch_async(dispatch_get_global_queue(0, 0), ^{

    NSLog(@"2");

    [self performSelector:@selector(test) withObject:nil afterDelay:10];

    NSLog(@"3");
});

NSLog(@"4");

- (void)test
{

    NSLog(@"5");
}

Copy the code

The answer is 1423, and the test method does not execute. The reason is that with afterDelay, an NSTimer is created internally and added to the RunLoop of the current thread. This method is invalid if the current thread does not have RunLoop enabled. So let’s change it to:

dispatch_async(dispatch_get_global_queue(0, 0), ^{

        NSLog(@"2");

        [[NSRunLoop currentRunLoop] run];

        [self performSelector:@selector(test) withObject:nil afterDelay:10];

        NSLog(@"3");
    });

Copy the code

However, the test method is still not executed. The reason is that if the mode of the RunLoop does not contain any item, the RunLoop exits. That is, after calling RunLoop’s run method, the RunLoop exits because there is no item added to its mode to maintain the RunLoop’s time loop. So let’s start RunLoop ourselves, after adding the item

dispatch_async(dispatch_get_global_queue(0, 0), ^{

        NSLog(@"2");

        [self performSelector:@selector(test) withObject:nil afterDelay:10];

        [[NSRunLoop currentRunLoop] run];

        NSLog(@"3");
    });

Copy the code
3. How to ensure that the child thread data comes back to update the UI without interrupting the user’s sliding operation?

When we slide through the current page while subrequesting data, if the data request succeeds and we switch back to the main thread to update the UI, the current slide experience will be affected. We can simply place the update UI event on NSDefaultRunLoopMode of the main thread, and then update the UI when the user stops sliding and the RunLoop of the main thread switches from UITrackingRunLoopMode to NSDefaultRunLoopMode

[self performSelectorOnMainThread:@selector(reloadData) withObject:nil waitUntilDone:NO modes:@[NSDefaultRunLoopMode]];

Copy the code

IOS interview question —– HTTP protocol related to network

HTTP: Hypertext transfer protocol

A data transfer protocol that specifies the rules for communication between the browser and the World Wide Web (WWW) server, and transmits World Wide Web documents over the Internet. HTTP is an application layer protocol based on TCP (the OSI network layer 7 protocols are the application layer, presentation layer, session layer, transport layer, network layer, data link layer, and physical layer from top to bottom).

  • Request/response packets
  • Connection Establishment Process
  • The characteristics of HTTP

Request packet and response packet

1. Request packet

As follows:

POST /somedir/page.html HTTP/1.1 // The above is the request line: method field, URL field and HTTP version field Host: www.user.com content-type: Application /x-www-form-urlencoded Connection: Keep-alive user-agent: Mozilla/5.0. accept-Lauguage: Fr // This is the first line (there must be an empty line) // The blank line separates the header from the request content name=world request bodyCopy the code

Connection: The keep-alive header line indicates that the browser is telling the server to use a content-type continuous Connection: X-www-form-urlencoded header line is used to show that HTTP will organize the request parameters with key1=val1&key2=val2 and put them into the request entity user-agent: The first line identifies the user agent, the type of browser that sent the request to the server accept-Lauguage: The first line indicates that the user wants the French version of the object (if the server has one); otherwise, the server should send its default version

2. Response packet

As follows:

HTTP/1.1 200 OK // Connection: close Server:Apache/2.2.3(CentOS) Date: Sat, 31 Dec 2005 23:59:59 GMT Content-Type: text/html Content-Length: 122 // This is the header line (there must be an empty line here)// The blank line separates the header and the entity body (data data data data)// The response entity bodyCopy the code
The status code and its corresponding phrase indicate the result of the request.

Some common status codes and corresponding phrases:

  • 200 OK: The request succeeds and the information is in the response packet
  • 301 Moved Permanently: The requested object has been Permanently Moved, and the new URL is defined in the Location: header row of the response packet. The client software will automatically get the new URL
  • 400 Bad Request: A common error code indicating that the Request was not understood by the server
  • 404 Not Found: The requested file is Not Found on the server
  • 505 HTTP Version Not Supported: The server does Not support the HTTP protocol Version used by the request packet. < Status codes starting with 4 are usually client problems, while status codes starting with 5 are usually server problems. >

Connection: The close header line tells the client that the TCP Connection will be closed after the packet is sent. Date: Not the time when the object is created or last modified, but the time when the server retrieves the object from the file system, inserts the object into the response packet, and sends the response packet. Server: The header line indicates that the packet is generated by an Apache Web server, similar to the user-agent content-Length in an HTTP request packet: The header line indicates the number of bytes in the sent object. Content-type: The header line indicates that the object in the entity is HTML text

Second, HTTP request mode

GET, POST, PUT, DELETE, HEAD, and OPTIONS
1. Differences between GET and POST modes
Grammatically, the most intuitive difference is
  • The request parameter of GET is usually?The POST request parameter is in the Body
  • GET parameters are limited to 2048 characters, and POST is generally unlimited
  • A GET request is insecure because its parameters are exposed in the URL, and a POST request is relatively secure because if the parameters of POST are non-plaintext, but if a packet is caught, then both GET and POST are insecure. (HTTPS)
And from a semantic perspective:

GET: Getting the resource is secure, idempotent (read only, pure), cacheable. POST: Getting the resource is insecure, non-idempotent, and not cacheable

  • Here,securityDo not cause any state change on the Server. The semantic meaning of GET is to obtain data. It does not cause any state change on the Server. (HEAD, OPTIONS are also safe.) The POST semantics are to submit data and may cause changes in server state, which is unsafe
  • Power etc.: Executing the same request method multiple times has exactly the same effect as executing it oncePower etc.The POST request isThe power etc.. It’s not enough to call GET idempotent, because not only does GET have exactly the same effect if it’s executed multiple times as if it’s executed once, but it also has exactly the same effect if it’s executed once as if it’s executed zero times.
  • cacheableWhether the request can be cached. GET requests are cached actively

The above features are not in parallel. It is because GET is idempotent and read-only, that is, the GET request will not have any side effects except the returned data. Therefore, GET is safe and can be cached directly by CDN, which greatly reduces the burden on the server. POST is non-idempotent, that is, it has other side effects besides returning data, so it is not secure and must be handled by the Web server, that is, it is not cacheable

GET and POST are essentially TCP links, no difference. However, due to HTTP regulations and browser/server restrictions, they are different in the application process.

In response, GET generates a TCP packet; POST generates two TCP packets: for a GET request, the browser sends the Header along with the entity body, and the server responds with 200 (returning data). For POST, the browser sends the Header, the server responds with 100 Continue, the browser sends the entity body, and the server responds with 200 OK (returning data).

2. What are the advantages of GET over POST?

The biggest advantage is convenience. The URL of the GET request can be typed directly, so that the URL of the GET request can be stored in the bookmark, or the history. 2. It can be cached, greatly reducing the burden of the server

So for the most part, it’s better to just use GET.

Three, THE characteristics of HTTP

Connectionless, stateless HTTP persistent connections, cookies/sessions

1. Stateless HTTP

That is, the protocol has no memory for transactions. Each request is independent, its execution and results are not directly related to the previous request and the subsequent request, it is not directly affected by the response to the previous request, it is not directly affected by the response to the subsequent request, so there is no state of the client stored in the server, The client must request the server with its own state every time. Standard HTTP protocol refers to the HTTP protocol that does not include cookies, sessions, and applications

2. Persistent HTTP connections

  • Non-persistent connections: Each connection handles one request-response transaction.

  • Persistent connections: Each connection can handle multiple request-response transactions.

In the case of persistent connections, the server sends a response and keeps the TCP connection open. Subsequent requests and responses between the same client/server can be sent through this connection. HTTP/1.0 uses non-persistent connections. HTTP/1.1 uses a persistent connection

by default.

For non-persistent connections, TCP has to allocate TCP buffers on both the client and the server and maintain TCP variables, which can significantly burden the server. Moreover, each object has two RTT(Round Trip Time) delays. Due to TCP’s congestion control scheme, each object suffers from TCP soft-start because every TCP connection starts in the soft-start phase

How does HTTP persistent connection determine if a request is terminated?
  • Content-length: according to whether the number of received bytes is reachedContent-lengthvalue
  • chunked(Block transfer):Transfer-Encoding. When block transmission is selected, the response header may not includeContent-Length, the server responds with a packet with no data (just the response line and header and \r\n), and then begins transmitting several data blocks. After several data blocks are transferred, an empty data block needs to be transferred. When the client receives an empty data block, it knows that the data reception is complete.

—– HTTPS, symmetric encryption, and asymmetric encryption related to the network

1. Differences between HTTPS and HTTP

HTTPS = HTTP + SSL/TLS SSL is Secure Sockets Layer. It is a security protocol that provides security and data integrity for network communication. The full name of TLS is Transport Layer Security. That is, HTTPS is secure HTTP.

2. HTTPS connection establishment process

For security and efficiency, HTTPS uses both symmetric and asymmetric encryption. There are three keys involved in the transmission:

  • The public and private keys on the server are used for asymmetric encryption

  • A random key generated by the client for symmetric encryption

As shown above, the HTTPS connection process can be roughly divided into eight steps:

1. The client accesses the HTTPS connection.

The client sends the security protocol version number, the list of encryption algorithms supported by the client, and the random number C to the server.

2. The server sends the certificate to the client

After receiving the key algorithm components, the server compares them with the list of supported encryption algorithms. If they do not match, the server disconnects. Otherwise, the server selects a symmetric algorithm (such as AES), a public key algorithm (such as RSA with a specific secret key length), and a MAC algorithm from the algorithm list and sends them to the client. The server has a key pair, namely the public key and the private key, which are used for asymmetric encryption. The server keeps the private key and cannot disclose it. The public key can be sent to anyone. In addition to the encryption algorithm, the digital certificate and random number S are sent to the client

3. Verify the server certificate on the client

The server public key is checked to verify its validity. If the public key is found to be faulty, the HTTPS transmission cannot continue.

4. The client assembles the session secret key

If the public key is qualified, the client generates a pre-master Secret (PMS) from the server’s public key, which is then assembled into a session Secret key with random numbers C and S

5. The client encrypts the former master key and sends it to the server

The former master key is asymmetrically encrypted using the public key of the server and sent to the server

6. The server obtains the former master secret key by decrypting the private key

After receiving the encrypted information, the server uses the private key to decrypt it to obtain the master secret key.

7. The server assembles the session secret key

The server assembles the session secret key from the former master secret key and random numbers C and S. At this point, both the server and client know the master secret key used for this session.

8. Data transmission

After receiving the ciphertext sent by the server, the client uses the client key to decrypt the ciphertext symmetrically to obtain the data sent by the server. Similarly, the server receives the ciphertext sent by the client and uses the server key to decrypt it symmetrically to obtain the data sent by the client.

Conclusion:

Session Secret key = Random S + Random C + former master key

  • HTTPS connection setup processAsymmetric encryptionAnd theAsymmetric encryptionIt’s a time-consuming form of encryption
  • Used in subsequent communicationSymmetric encryptionTo reduce the performance cost caused by time consumption
  • Among them,Symmetric encryptionThe encryption is the actual data,Asymmetric encryptionThe encryption is the client key required for symmetric encryption.

Three, symmetric encryption and asymmetric encryption

1, symmetric encryption

Use the same set of keys for encryption and decryption. Symmetric encryption usually has DES,IDEA,3DES encryption algorithm.

2. Asymmetric encryption

Algorithms for encryption and decryption using public and private keys. A Public Key and a Private Key are a Key pair obtained through an algorithm. The Public Key is the Public part of a Key pair, and the Private Key is the Private part. The Private Key is usually stored locally.

  • To encrypt with the public key, decrypt with the private key; Conversely, encryption with the private key requires decryption with the public key (digital signature).

  • Because the private key is stored locally, asymmetric encryption is safer than symmetric encryption. However, asymmetric encryption is more time-consuming than symmetric encryption (more than 100 times), so it is usually used in combination with symmetric encryption.

Common asymmetric encryption algorithms include RSA, ECC (for mobile devices), Diffie-Hellman, El Gamal, and DSA (for digital signatures).

In order to ensure that the client can confirm that the public key is the public key of the website that it wants to visit, the concept of digital certificate is introduced. As there is a process of issuing certificates, there is a certificate chain, and the root CA is at the top of the certificate chain.

Xiii. IOS interview —– a simple CHAT Demo based on UDP (with C language, Python, GCDAsyncUdpSocket to achieve UDP communication)

First, using C language, Python, GCDAsyncUdpSocket to achieve UDP communication

1. C language
  • First initializesocketObject that Udp needs to useSOCK_DGRAM
  • And then initializesockaddr_inA network communication object, if bound as a serversocketObject with a communication link to receive messages
  • Then open a loop and loop the callrecvfromTo receive a message
  • After receiving a message, save the address of the message object to reply the message later
- (void)initCSocket { char receiveBuffer[1024]; __uint32_t nSize = sizeof(struct sockaddr); if ((_listenfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) { perror("socket() error. Failed to initiate a socket"); } bzero(&_addr, sizeof(_addr)); _addr.sin_family = AF_INET; _addr.sin_port = htons(_destPort); if(bind(_listenfd, (struct sockaddr *)&_addr, sizeof(_addr)) == -1) { perror("Bind() error."); } _addr.sin_addr.s_addr = inet_addr([_destHost UTF8String]); INADDR_ANY = 0.0.0.0, INADDR_ANY = 0.0.0.0 While (true){long strLen = recvfrom(_listenfd, receiveBuffer, sizeof(receiveBuffer), 0, (struct sockaddr *)&_addr, &nSize); NSString * message = [[NSString alloc] initWithBytes:receiveBuffer length:strLen encoding:NSUTF8StringEncoding]; _destPort = ntohs(_addr.sin_port); _destHost = [[NSString alloc] initWithUTF8String:inet_ntoa(_addr.sin_addr)]; NSLog (@ "from % @ lh-zd: - % % @", _destHost, _destPort, message); }}Copy the code
  • To avoid blocking the main thread, the while loop is open to receive messages all the timeinitCSocketFunctions are called in child threads
dispatch_async(dispatch_get_global_queue(0, 0), ^{

        [self initCSocket];
    });

Copy the code
  • callsendtoMethod to send a message
- (void)sendMessage:(NSString *)message
{
    NSData *sendData = [message dataUsingEncoding:NSUTF8StringEncoding];

    sendto(_listenfd, [sendData bytes], [sendData length], 0, (struct sockaddr *)&_addr, sizeof(struct sockaddr));
}

Copy the code
2. GCDAsyncUdpSocket mode
  • GCDAsyncUdpSocket address
  • First initialize the Socket object

  • Bind the port and call beginReceiving: to receive the message

- (void)initGCDSocket { _receiveSocket = [[GCDAsyncUdpSocket alloc] initWithDelegate:self delegateQueue:dispatch_get_global_queue(0, 0)]; NSError *error; [_receiveSocket bindToPort:test_port error:&error]; If (error) {NSLog(@" server binding failed "); } // Start receiving messages [_receiveSocket beginReceiving:nil]; }Copy the code
  • Get the message from the peer in the proxy method, record the host and port so that you can reply to the message later
#pragma mark - GCDAsyncUdpSocketDelegate - (void)udpSocket:(GCDAsyncUdpSocket *)sock didReceiveData:(NSData *)data fromAddress:(NSData *)address withFilterContext:(id)filterContext { NSString *message = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding]; _destPort = [GCDAsyncUdpSocket portFromAddress:address]; _destHost = [GCDAsyncUdpSocket hostFromAddress:address]; NSLog (@ "from % @ lh-zd: - % % @", _destHost, _destPort, message); }Copy the code
  • callsendData:(NSData *)data toHost:(NSString *)host port:(uint16_t)port withTimeout:(NSTimeInterval)timeout tag:(long)tagMethod to send a message
- (void)sendMessage:(NSString *)message
{
    NSData *sendData = [message dataUsingEncoding:NSUTF8StringEncoding];

    [_receiveSocket sendData:sendData toHost:_destHost port:_destPort withTimeout:60 tag:500];
}

Copy the code
3. Python

The Python approach is simpler

  • Initialize the socket and bind the port
socket = socket(AF_INET, SOCK_DGRAM)

socket.bind(('', port))

Copy the code
  • Circular receive message
while True:
    message, address = socket.recvfrom(2048)
    print address,message

Copy the code
  • Send a message
socket.sendto(message, address)

Copy the code

Second, using Python to achieve Udp communication demo

  • Create two Python files, one as client and one as server, and run them simultaneously

  • The client

From socket import * host = '127.0.0.1' port = 12000 socket = socket(AF_INET, SOCK_DGRAM) while True: message = raw_input('input message ,print 0 to close :\n') socket.sendto(message, (host, port)) if message == '0': socket.close() break receiveMessage, serverAddress = socket.recvfrom(2048) print receiveMessage,serverAddressCopy the code
  • The service side
from socket import *
port = 12000
socket = socket(AF_INET, SOCK_DGRAM)
socket.bind(('', port))
print 'server is ready to receive'
count = 0
while True:
    message, address = socket.recvfrom(2048)
    print address,message
    count = count + 1
    if message == '0':
        socket.close()
        break
    else:
        message = raw_input('input message ,print 0 to close :\n')
        socket.sendto(message, address)

Copy the code
  • Client print
/ usr/local/bin/python2.7 / Users/wangyong/Desktop/other/python/UDPClient py input message, print 0 to close: Print ('10.208.61.53', 12000) input message,print 0 to close: ('10.208.61.53', 12000) Input message,print 0 to close: 0 Process finished with exit code 0Copy the code
  • Server print
/ usr/local/bin/python2.7 / Users/wangyong/Desktop/other/python/UDPServer py server is ready to receive (' 10.208.61.53 ', 53500) Hello, server input message,print 0 to close: Hello, client ('10.208.61.53', 53500) Ok ('10.208.61.53', 53500) 0 Process Finished with exit code 0Copy the code

3. Simple CHAT demo based on UDP on iOS

1, UdpManager

Udp communication C version and GCDAsyncUdpSocket can be encapsulated in UdpManager

  • initSocketWithReceiveHandle:(dispatch_block_t)receiveHandle: related to initializing the socket, receiveHandle is a callback after receiving a message
  • sendMessage:(NSString *)message: Sends a message
  • messageArray: Message list, including received and sent messages
+ (void)initSocketWithReceiveHandle:(dispatch_block_t)receiveHandle;

+ (void)sendMessage:(NSString *)message;

+ (NSMutableArray *)messageArray;

Copy the code

The message content is MessageModel, where role represents the message sending object. 0 indicates the received message, and 1 indicates the message sent by the user

@interface MessageModel:NSObject

@property (nonatomic, copy) NSString *message;

@property(nonatomic,assign) NSInteger role;

@end

Copy the code
2, ViewController

UdpManager is called in the controller to initialize the socket

[UdpManager initSocketWithReceiveHandle:^{

        dispatch_async(dispatch_get_main_queue(), ^{

            self.title = [NSString stringWithFormat:@"%@---%@",[[UdpManager shareManager] valueForKey:@"_destHost"],[[UdpManager shareManager] valueForKey:@"_destPort"]];

            [self reloadData];
        });
    }];

Copy the code

Send the edited message when the proxy method textFieldShouldReturn is clicked on the keyboard’s send button

#pragma mark - UITextFieldDelegate
- (BOOL)textFieldShouldReturn:(UITextField *)textField
{
    if (self.textField.text.length == 0) return YES;

    [UdpManager sendMessage:self.textField.text];

    [self reloadData];

    self.textField.text = nil;

    return YES;
}

Copy the code

When a new message is sent or received, the message is added to the messageArray and the page is refreshed

- (void)sendMessage:(NSString *)message { NSData *sendData = [message dataUsingEncoding:NSUTF8StringEncoding]; [self.messageArray addObject:[[MessageModel alloc] initWithMessage:message role:1]]; #ifdef UseGCDUdpSocket #ifdef UseGCDUdpSocket #ifdef UseGCDUdpSocket Instead of sending the data immediately after the function call is completed, the data is sent asynchronously [_receiveSocket sendData:sendData toHost:_destHost Port :_destPort withTimeout:60 tag:500]; #else sendto(_listenfd, [sendData bytes], [sendData length], 0, (struct sockaddr *)&_addr, sizeof(struct sockaddr)); #endif }Copy the code

I’m not going to go into the UI, but the controller has a tableView that shows a list of the contents of the received and sent messages and a textField that’s an input field for editing messages. About these content, just a simple demo, only to receive and send text message function, and did not do more optimization

3, test,

Run it on an emulator and a real machine, or you can test it with the Python program you just wrote. Test_host just uses the computer IP

  • The phone then sends the message first to the simulator, which then responds to the message based on the host and port of the recorded phone. You can also connect your phone to the Internet here
  • The renderings are shown below

IOS Interview question —– Network related FEATURES of UDP, UDP packet structure and error detection

Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) belong to the same categoryThe transport layeragreement

1. Characteristics of UDP

UDP is a connection-oriented protocol. To transmit data, you do not need to connect to a server, but only need to know the IP address and listening port. You do not need to connect to a purposeless socket. Since UDP is an unreliable data transfer protocol, why do so many applications choose it?

1. More fine-grained application layer control over when and what data is sent
  • As soon as the application passes the data to UDP, UDP packages the data into a UDP packet segment and immediately passes it to the network layer.
  • TCP, on the other hand, has a congestion control mechanism to ensure that data can be safely transmitted, no matter how long it takes for reliable transmission to succeed.
  • Therefore, some real-time applications, such as wechat video and voice, prefer data to be sent in a timely manner, for which some data loss can be tolerated, and UDP is more suitable
2. No connection needs to be established
  • As we all know, TCP requires three handshakes before data is transmitted, but UDP does not require any preparation to transmit data, so UDP does not introduce the delay of establishing a connection.
  • This is the main reason why DNS runs on UDP instead of TCP.
  • The HTTP protocol uses TCP because reliability is critical to HTTP.
3. No connection
  • TCP needs to maintain the connection state. This connection state includes receive and send caches, congestion control parameters, and sequence and acknowledgement number parameters. (For TCP’s congestion control scheme, which will be detailed later if there is time, these state messages are necessary)
  • UDP does not need to maintain connection state or track these parameters
4. Small group header overhead

Each TCP segment has a header cost of 20 bytes, while UDP only has an overhead of 8 bytes

So, if it is not necessary, such as E-mail, remote terminal services, the Web, and file transfer, to transfer data reliably, TCP will be used. Other applications, especially those requiring high real-time performance, such as real-time video conferencing and voip, generally use UDP

2. UDP packet structure

Data at the application layer occupies data fields in UDP packet segments. The UDP header contains only four fields. Each field consists of two bytes. That is, the UDP header contains only eight bytes.

  • Port number: enables the destination host to transfer application data to corresponding processes running in the destination system for sharing.

  • Length: This field indicates the number of bytes in a UDP segment (header + data).

  • Check and: The receiver uses the check and to check whether an error has occurred in the paragraph.

UDP error detection

UDP validation and provides error detection capabilities. The validation and equivalence is used to determine whether bits in a UDP packet segment have changed as it moves from the source to the destination (for example, due to noise interference in the link or import problems when stored on the router). The sender’s UDP performs the inverse code operation on all 16-bit pairs in the segment, and any overflows encountered during summation are rolled back. The result is put into the validation and field in the UDP packet segment.

For example, consider the following three 16-bit words:

0110011001100000
0101010101010101
1000111100001100

Copy the code

The first two of these 16-bit words add up to:

1011101110110101

Copy the code

This sum is then added to the third 16-bit word to give:

10100101011000001

Copy the code

If the overflow is found, the and will be rolled back. That is, add the first digit 1 to the last digit to get:

0100101011000010

Copy the code

And then you invert it, and then you invert it, which means you replace all the ones with zeros, and the zeros with ones

1011010100111101

Copy the code

So that’s the test sum that comes out. On the receiving end, all four 16-bit words (including check and) are added together. If no error is introduced in the packet, obviously the sum will be 1111111111111111 at the receiving end. And if one of those bits is zero, then we know there’s something wrong with that grouping. UDP provides error detection at the transportation layer on an end-to-end basis, which is the end-to-end principle enshrined in system design

While UDP provides error detection, it does nothing for error recovery. This is where reliable data transmission –TCP — comes in

15. IOS interview questions —– Network related TCP, three handshake, four wave, code implementation

I. CHARACTERISTICS and packet structure of TCP

1, connection oriented, reliable transmission, byte stream oriented, full duplex service
2. TCP packet structure

A TCP packet segment consists of a header field and a data field. The data field contains a block of application data. Maximum Segment Size (MSS) Limits the Maximum length of data fields in a packet Segment. When a TCP connection is established, the MSS option is used to negotiate the maximum length of data that can be carried by each packet segment. So when TCP sends a large file (such as a high-definition image), it usually divides the file into chunks of MSS length (except for the last one, which is usually smaller than the MSS). However, actual interactive applications usually transmit data blocks of less length than MSS.

As shown in the figure, like UDP, the header contains the source and destination port numbers for multiplexing/shredding data from or to upper-layer applications. The TCP header also contains validation and fields. The TCP header also contains the following fields:

  • 32 bitSeq(Sequence number field)And 32 bitsAck(acknowledge Number Field)
  • 16 bits ofRW(Receive Window Field)This field is used for flow control and is used to indicate the number of bytes the receiver is willing to receive.
  • 4 bits,Header Length FieldThis field indicates the TCP header length in 32-bit words. The TCP header length is variable due to the TCP option field. (Normally, the options field is empty, so the typical TCP header is 20 bytes.)
  • Optional and lengthenedOption fieldThis field is used when the sender and receiver negotiate the maximum segment length (MSS), or when the sender and receiver are used as a window adjustment factor.
  • 6 bits,Flag Field.ACKThe bit is used to indicate that the value in the acknowledgment field is valid, that is, the segment includes an acknowledgment that the segment has been received.RST,SYN,FINBits are used for connection establishment and disconnection.PSHThe bit indicates that the receiver should immediately hand over the data to the upper layer.URGBits are used to indicate the presence of data in the segment that is set to “urgent” by the upper-layer entity of the sending end. The last byte of the emergency data is indicated by the 16-bit emergency data pointer field. TCP must notify the upper-layer entity at the receiving end when the emergency data exists and gives a pointer to the tail of the emergency data. In practice, the PSH, URG, and emergency data Pointers are not used.
3. The serial number field Seq and the confirmation number field Ack
  • In TCP communication, Seq value and Ack value are inseparable from connection establishment, data transmission, friendly disconnection and forced disconnection. They are the reliable guarantee of TCP transmission.

Seq: TCP treats data as an unstructured, ordered byte stream. The sequence number of a segment is therefore the byte stream number of the first byte of the segment. For example, a data stream consists of a file containing 100000 bytes, its MSS is 1000 bytes, and the first byte number of the data stream is 0. The TCP will build 100 segments for the data flow. Assign sequence number 0 to the first segment, 1000 to the second segment, 2000 to the third segment, and so on. Each sequence number is filled in the sequence number field at the beginning of the corresponding TCP packet segment. Acknowledgement NUMBER Ack: TCP is A full-duplex service, so host A may be receiving data from host B at the same time as sending data to host B. The acknowledgment number that host A fills in the segment is the sequence number of the next byte that host A expects to receive from host B.

In the previous example, if the server has received the segment containing bytes 0-999 and 2000-2999, but for some reason has not received the segment containing bytes 1000-1999, it will still wait for byte 1000 (and subsequent bytes). Therefore, the next segment sent by the server to the client will contain 1000 in the Ack field of the acknowledgement number. Because TCP recognizes only the bytes in the stream up to the first lost byte, TCP is called cumulative acknowledgment.

Two or three handshakes

– Before the data starts to transfer, a three-way handshake is needed to establish the connection. In fact, I think it’s better called a three-way handshake

The first step:

  • The TCP on the client first sends a special TCP packet segment to the TCP on the server. This packet does not contain application-layer data and is one of the first packets in the packetFlag bit (SYN bit)Is set to 1, so the paragraph is calledThe SYN segment. In addition, the customer chooses an initial serial number at randomclient_isnAnd place the sequence number on the starting TCPSYNIn the sequence number field of the packet segment.
  • Both the client and the server start atCLOSEDStatus: Sent theSYNAfter the packet segment, the CLIENT TCP entersSYN_SENTThe segment that waits for acknowledgement from the server and sets the SYN bit to 1.

The second step:

  • After receiving the SYN packet segment, the server allocates TCP cache and variables for the TCP connection, and the server TCP entersSYN_RCVDStatus, waiting for the client TCP to send the acknowledgement packet segment.
  • The TCP client sends a packet segment that allows connections. The packet segment also does not contain application-layer data. At the head of the paragraphSYNThe bit is set to 1 and the confirmation number field is set toclient_isn+ 1. The server also chooses its initial serial numberserver_isnIs placed in the sequence number segment at the beginning of the packet segment. The connection is calledSYNACK message segment.

Step 3:

  • After receiving a SYNACK packet segment, the client also allocates cache and variables for the TCP connection, and the client TCP entersESTABLISHEDState in which the client can send and receive a segment containing payload data.
  • And sends a segment to the server TCP: this last segment represents the acknowledgement of the server’s permit to connectserver_isn+ 1 is placed in the acknowledgment field at the beginning of the segment. Since the connection is already established, it’s timeSYNThe bit is set to 0. At this stage, application-layer data can be carried in the segment payload.
  • After receiving the packet from the client, TCP on the server also enters the packetESTABLISHEDStatus, which can send and receive segments containing payload data.

Three or four waves

Either of the two processes involved in a TCP connection can terminate the connection, and when the connection ends, resources (caches and variables) on the host are released.

As mentioned above, the SYN and FIN flags correspond to the establishment and disconnection of a TCP connection, respectively.

As shown in figure,

The first step:

  • The client application process issues a command to close the connection. The client TCP sends a special TCP packet segment to the server. The text is a flag bit of the headerFINThe bit is set to 1.
  • At the same time, the client entersFIN_WAIT_1Status, waiting for the TCP packet segment with acknowledgement on the server.

The second step:

  • After receiving the packet, the SVN sends an acknowledgement packet to the client.
  • TCP entry on the serverCLOSE_WAITStatus, corresponding to the clientTIME_WAIT, indicating that it is passively closed.
  • After receiving the packet, the client entersFIN_WAIT_2Status, waiting for the serverFINThe segment whose bit is set to 1.

Step 3:

  • The server sends its own end segment, again using the flag bit at the beginning of the segmentFINThe bit is set to 1.
  • TCP entry on the serverLAST_ACKStatus, waiting for the last acknowledgement packet segment from the server.

Step 4:

  • After receiving the termination packet segment from the server, the client sends an acknowledgement packet segment to the server. At the same time, the client entersTIME_WAITState.
  • If the ACK is lost,TIME_WAITStatus causes the TCP client to retransmit the last acknowledgement packet,TIME_WAITGenerally, the system waits for 2MSL. After waiting, the connection is officially closed and re-enteredCLOSEDStatus: All resources on the client will be released.
  • When the server receives the packet, it also closes and re-entersCLOSEDTo release all TCP resources on the server.

Four, some problems

Q: Why do you use three handshakes to establish a connection and four waves to disconnect it?
  • First, when the client has sent all the data and knows that the server has received all the data, it will disconnect the connection and send a FIN to the server
  • After receiving the FIN from the client, the server sends an ACK to the client
  • However, the server may still be sending data without closing the TCP window. Therefore, the FIN and ACK of the server are not sent at the same time. The FIN is sent only when the data is sent
  • A: The SERVER FIN and ACK need to be developed separately. Unlike the three-way handshake, where the SYN and ACK can be sent simultaneously, four waves are required
2. In four waves, why does the client have to wait 2MSL after TIME_WAIT?

The ACK packet segment may be lost. As a result, the server on the LAST_ACK end cannot receive the ACK packet segment of the sent FIN packet segment. As a result, the server repeatedly retransmits the FIN packet segment. The client can receive the retransmitted FIN segment within 2MSL. The client then retransmits a confirmation and restarts the 2MSL timer. After the server receives the packet, both the client and the server enter the CLOSED state and close the TCP connection. However, if the client does not wait for 2MSL time but releases resources immediately after sending ACK confirmation and closes the connection, it cannot receive the REtransmitted FIN packet segment from the server and therefore does not send ACK acknowledgement packet segment again. In this way, the server cannot enter the CLOSED state normally and the resources cannot be released.

  • A: To ensure that the client sends the last oneACKThe packet segment can reach the server.
3. Why does TCP require three handshakes when creating a connection instead of two or four?

A simple example:

  • Three-way handshake“Hello, can you hear me? “I can hear you, can you hear me?” “I can hear you today Balabala…”
  • Two shake hands“Hello, can you hear me? “I can hear you, can you hear me?” “Hello, can you hear me? “… Who’s talking?” “Hello, can you hear me? “……”
  • Four times to shake hands“Hello, can you hear me? “I can hear you.” “Can you hear me? “… Don’t want to talk to idiots.”

It’s easy to understand why you don’t use a four-way handshake. It’s a waste of resources. The server’s SYN and ACK can be sent together.

In the case of two handshakes, the SYN segment of the first connection request from the client is not lost, but is delayed at a certain network node until some time after the connection is released. Originally, this was an invalid segment. However, after receiving the invalid SYN packet, the server mistook it for a new one sent by the client. An ACK segment is sent to the client, agreeing to establish a connection. Assuming the three-way handshake is not used, a new connection is established as soon as the server issues an acknowledgement. Since the client has not now made a SYN request to establish a connection, the acknowledgement from the server is ignored and no data is sent to the server. But the server thinks a new shipping connection has been established and waits for the client to send data. A lot of resources are wasted on the server side.

In fact, TCP acknowledges the TCP segment that contains data. Therefore, the client must acknowledge the SERVER’s SYN segment with an ACK packet. In addition, TCP does not retransmit packets with no data timed out. Therefore, if the server does not receive an ACK acknowledgement packet from the client, it will retransmit its OWN SYN packet segment timed out until it receives an ACK from the client.

  • A: A two-time handshake may cause an invalid connection request segment to be suddenly sent to the server, and a four-time handshake is a waste of resources

Five, code implementation

A simple UDp-based chat Demo (with C language, Python, GCDAsyncUdpSocket to achieve UDP communication) reference UDP code, in fact, TCP in the code implementation is also very similar, First, ·socket· is initialized with ·SOCK_DGRAM instead of ·SOCK_DGRAM·

fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

Copy the code

The TCP server has an additional process to listen for and accept connections:

int listen_ret = listen(fd,5);
int listen_socket = accept(_fd,(sockaddr *)&addr,&addr_len);

Copy the code

UDP is the process of adding one more connection:

int ret = connect(_fd, (struct sockaddr *) &addr, sizeof(addr));

Copy the code

Then, when receiving and sending data, there is no need to transmit the host and port. That is, recv and send are changed from recvFROM and sendto.

send(_fd, [buffer bytes], [buffer length], 0);
recv(_fd, receiveBuffer, sizeof(receiveBuffer), 0);

Copy the code

The python client code is as follows:

From socket import * serverName = '127.0.0.1' serverPort = 12000 clientSocket = socket(AF_INET,SOCK_STREAM) clientSocket.connect((serverName,serverPort)) sentence = raw_input('Input lowercase:\n') clientSocket.send(sentence) modifiedSentence = clientSocket.recv(1029) print 'From server:\n',modifiedSentence clientSocket.close()Copy the code

Server code:

from socket import *
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind(('',serverPort))
serverSocket.listen(1)
print 'server is ready to receive'
connectionSocket,addr = serverSocket.accept()
sentence = connectionSocket.recv(1029)
capitalizeSentence = sentence.upper()
print capitalizeSentence
connectionSocket.send(capitalizeSentence)
connectionSocket.close()
Copy the code

—– Networking related TCP advancements: reliable data transmission, flow control (sliding window), congestion control

1. Reliable data transmission

Network layer services (IP services) are unreliable. IP does not guarantee the delivery of datagrams, the sequential delivery of datagrams, or the integrity of the data in the datagrams.

TCP, on the other hand, creates a reliable data transfer service over THE IP service. TCP’s reliable data transfer service ensures that the data streams read by a process from its receive cache are uncorrupted, unspaced, non-redundant, and sequential. That is, the byte stream is identical to the byte stream emitted from the other end of the connection. As a TCP receiver, there are three main events related to send and retransmit

1. Receive data from upper-layer application data

Encapsulate data into a segment and deliver the segment to the IP address. Each packet segment contains a sequence number Seq, that is, the byte stream number of the first data byte of the packet segment. If the timer is not running for other message segments, start the timer (that is, start only one timer for each message segment). The expiration interval of the timer is TimeoutInterval calculated by EstimatedRTT and DevRTT: the estimate and timeout of the TCP round-trip time

2, the timeout

TCP responds to the timeout event by retransmitting the timed out packet segments and restarting the timer.

The sender times out in two ways: sending data times out, and receiving ACK times out. In either case, the sender cannot receive THE ACK acknowledgement packet segment within TimeoutInterval.

  • 1. If the data transmission times out, directly retransmit the data.
  • 2. If the receiver sends an ACK timeout, the receiver has actually received the data from the sender. In this case, when the sender retransmits the data due to timeout, the receiver will discard the retransmitted data and send an ACK again.

If an ACK is received after the TimeoutInterval, it will be accepted, but nothing will be done about it

  • TCP does not retransmit an ACK timeout without data

In the following two cases:

  • 1. If two or more data packet segments time out, only the one with the smallest sequence number is retransmitted and the timer is restarted. As long as the ACK of the remaining packet segments arrives before the timeout of the newly restarted timer, the retransmission will not occur.
  • 2. If the sending number is100and120The serial number of the two data segments100ACK is lost, but the serial number is received120Because of the cumulative acknowledgement mechanism, the ACK can conclude that the receiver has received the serial number100In this case, it will not be retransmitted.
3. ACK is received

Use the TCP status variable SendBase to refer to the sequence number of the earliest unacknowledged byte. Sendbase-1 is the sequence number of the last byte of the data received by the receiver in the correct order. After receiving an ACK acknowledgement packet, the system compares the ACK value Y with SendBase. TCP uses the cumulative acknowledgment method, so Y acknowledges that all bytes numbered before Y have been received. If Y is smaller than SendBase, ignore it; If Y is larger than SendBase, then the ACK is acknowledging one or more previously unacknowledged segments, so the SendBase variable needs to be updated. If there are still unacknowledged segments, TCP restarts the timer.

By time-out retransmission, the data received is guaranteed to be a corruption-free, non-redundant data stream, but it is not guaranteed to be sequential.

And through THE TCP sliding window, can effectively ensure the order of received data

Two, flow control

Both hosts on both sides of a TCP connection allocate caches and variables to the TCP connection. When the correct, sequential bytes are received by the TCP connection, the data is placed in the receive cache. The upper-layer application process reads data from this cache, but it doesn’t have to be as soon as the data arrives, because the application may be doing other transactions. If the application layer reads data relatively slowly and the sender sends too much, too fast, the sent data can easily overflow the receive cache for that connection.

Therefore, TCP provides flow-control services for applications to eliminate the possibility that the sender will overflow the receiver’s cache.

Flow control is a speed-matching service where the rate at which the sender sends matches the rate at which the receiver application reads.

As a full-duplex protocol, each side of a TCP session maintains a send window and a receive Window variable to provide flow control. The size of the sending window is determined by the receiving window, which is used to give the sender an indication of how much cache space is available.

1. Send window

The data in the sender’s send cache can be divided into four categories:

  1. Sent, ACK received
  2. Sent, but no ACK was received
  3. Not sent, but allowed to send
  4. Not sent, but not allowed to send

Then 2 and 3 belong to the send window

  • Send windowOnly receivedSend windowTo move the left edge of the send window
2. Receiving window

The cache data of the receiver falls into three categories: 1 received 2 not received but ready to receive 3. Not received and not ready to receive 2 belongs to the receive window (receive here means receive data and acknowledge)

  • Receiving windowThe left boundary is moved only if all previous segments are confirmed. If there is a byte that is not received but a byte that is received, it will be received first,Receiving windowIt does not move and does not send ACK packets to subsequent bytes to ensure that the sender will retransmit the data.

We define the following variables:

  • LastByteRead: The last byte number of the data stream read by the receiving application. We know that this isReceive bufferThe starting point of the
  • LastByteRcvd: Arrived from the network and has been put inReceive bufferThe last of its own numbers in the data stream.

It can be learned: Lastbytercvd-lastbyteread <= RcvBuffer(size of the receive buffer) If RWND is 0, it means that the receive cache is full. The receiver will include the RWND in the ACK sent back to the sender, and the sender will control the sending window according to the value of the receiving window in the ACK.

There is a problem if the sender stops sending data after sending an ACK with RWND 0. After a period of time, the receiver application reads part of the data, and the receiver can continue to receive the data, so it sends a packet to the sender to tell the sender the size of the receiving window, but the packet is unfortunately lost. As we know, ACK without data will not be retransmitted due to timeout. Then there is the sender waits to receive the ACK notice | | receiving end waiting for the sender to send data of a deadlock state.

To deal with this problem, TCP introduces the Persistence timer. When the sender receives the ACK notification of RWND =0, it will enable this timer. When the time is up, it will send a 1-byte probe packet. Reset the duration timer and continue to wait.

3. Congestion control

In addition to reliable transport services, another key part of TCP is congestion control. TCP lets each sender limit the rate at which it can send traffic to a connection based on perceived network congestion. There may be three questions: 1. How does a TCP sender perceive network congestion? 2. How does a TCP sender limit the rate at which it sends traffic to a connection? 3. What algorithm does the sender use to change its sending rate when it perceives network congestion? This is TCP’s congestion control mechanism. As mentioned earlier, each end of a TCP connection consists of a receive cache, a send cache, and several variables (LastByteRead, LastByteRcvd, RWND, etc.). The TCP congestion control mechanism running at the sender tracks an additional variable, called CWND (congestion Window). It limits the rate at which a TCP sender can send traffic to the network. The amount of unacknowledged data in the sender does not exceed the minimum value for CWND and RWND :min(RWND, CWND)

1. How does a TCP sender perceive network congestion?

Duplicate ACK: Indicates an ACK that reconfirms a packet segment that the sender has previously received.

Causes of redundant ACK:
  • 1. The receiver receives the packetOut-of-sequence segment, that is, the sequence number of the packet segment is greater than the next expected packet segment in sequence. The interval in the data flow is detected, that is, the packet segment is lost, and the packet segment is not acknowledged. TCP is not usedNo confirmation, so an explicit negative acknowledgement cannot be sent to the sender. In order to make the receiver aware of this phenomenon, the previous sequential byte of data is processedRepeated confirmation“, which produces aRedundant ACK.
  • 2. The sender often sends a large number of packet segments. If a packet segment is lost, a large number of packets may be received before the timer expiresRedundant ACK. Once you receive threeRedundant ACK(If the number of packets is less than three, it is probably caused by the out-of-order of the link layer, and no action is required.) Indicates that the packet segment after the packet segment that has been acknowledged for three times is lost, and TCP executes the packetThe fast retransmissionThat is, the lost packet segment is retransmitted before its timer expires.
Will TCP senderPacket loss eventDefined as: either a timeout occurs or 3 are received from the receiverRedundant ACK.

When excessive congestion occurs, the router’s cache overflows, causing a datagram to be discarded. The discarded datagram then causes a packet loss event from the sender. At this point, the sender assumes that there is network congestion on the path from the sender to the receiver.

2. How does a TCP sender limit the rate at which it sends traffic to a connection?
  • When a packet loss event occurs: The rate of the TCP sender should be reduced.
  • When the acknowledgement of the previously unacknowledged segment arrives, that is, when a non-redundant ACK is received, the rate of the sender should be increased.
3. What algorithm does the sender use to change its sending rate when it perceives network congestion?

The TCP congestion control algorithm consists of three main parts: slow start, congestion avoidance, and fast recovery. Fast recovery is not necessary for the sender, while slow start and congestion avoidance are mandatory by TCP

  • 1. Slow startWhen a TCP connection starts, the window is congestedcwndThe value of is usually set to oneMSSThis makes the initial send rate approximatelyMSS/RTT(RTT: round-trip delay, the amount of time between the time a packet is sent and the acknowledgement of the packet is received.) For TCP senders, the available bandwidth may be less thanMSS/RTTMuch larger,TCP senders want to quickly find the amount of bandwidth available. So, in the slow start state,cwndWith aMSSAnd every time a non is receivedRedundant ACKJust add oneMSS.

As shown, the initial CWND value is 1MSS and a segment M1 is sent. After receiving the acknowledgement from M1, CWND is increased to 2MSS, and two segments M2 and M3 can be sent. After receiving the acknowledgement of the two segments, the CWND is increased to 4MSS and can send up to four segments, and so on…

Therefore, although the TCP transmission rate starts slowly, it increases exponentially during the slow start.

This exponential growth is obviously not unlimited, so when does it end? If a packet loss event occurs, the TCP sender sets SSthRESH (slow start threshold) to CWND /2

  • A packet loss event due to timeout occurs, and CWND is reset to 1MSS, and restart slowly

  • When the TCP sender’s CWND value reaches or exceeds SSthresh, it is clearly not appropriate to continue doubling. The end slow start is then moved to congestion avoidance mode.

  • When the TCP sender detects three redundant ACK packets, the TCP sender stops the slow start and quickly retransmits the lost packet segment before the packet segment timer expires. And enter the rapid recovery state.

  • 2. Congestion avoidance Once entering the congestion avoidance state, the value of CWND is about half that of the last time the congestion was encountered, that is, it is not far away from the congestion. Therefore, TCP cannot double the CWND every time an RTT is passed. Instead, each RTT is increased by only 1MSS, that is, CWND is increased by 1/ CWND for each non-redundant ACK received. That is, if the CWND is 10MSS, the CWND increases by 1/10MSS every time a non-redundant ACK is received, and the congestion window value increases by 1MSS after all 10 segments receive an acknowledgement.

So when will the linear growth of congestion avoidance (1MSS per RTT) end? As with slow start, if a packet loss event occurs, the TCP sender sets' ssthresh '(slow start threshold) to' CWND /2 '(addition increases, multiplication decreases)Copy the code
  • When a packet loss event is caused by timeout, congestion is avoided in the same way as slow start. That is, the TCP sender sets SSthRESH (Slow start threshold) to CWND /2 and resets CWND to 1MSS to restart the slow start

  • The TCP sender detects three redundant ACK’s, the CWND is half of the original plus 3MSS, and enters the fast recovery state.

  • 3. Quick recovery

The fast recovery is caused by three redundant ACK’s. In fast recovery, CWND adds one MSS for each redundant ACK received for the missing segment that causes TCP to enter the fast recovery state. Finally, when an ACK arrives for the lost segment, TCP enters the congestion avoidance state after reducing CWND. If a timeout occurs, the same as before, that is, the TCP sender sets SSthRESH (Slow start threshold) to CWND /2 and resets CWND to 1MSS to restart the slow start

A quick recovery is not necessary.

TCP congestion control is: the CWND in each RTT linear (incremental) increase by 1MSS, and then the CWND in the occurrence of 3 redundant ACK events halved (multiplicative reduction), so TCP congestion control is often referred to as incremental, multiplicative reduction congestion control mode.

17. IOS interview question —– Network-related cookies and sessions

A, Cookie,

The HTTP protocol is stateless. The server does not store the state of the client. The client must bring its own state to the server every time it requests the server

1. Interaction between user and server: Cookie

Cookies are mainly used to record user status and distinguish users. The state is saved on the client.

  • 1. First visitamazonThe client sends an HTTP request to the server. The server sends an HTTP response to the client containingSet-CookieThe head
  • 2. The client sends an HTTP request to the serverCookieThe head. The server sends an HTTP response to the client
  • 3. If you try to access the IP address again after a period of time, the client directly sends the IP addressCookieHeader HTTP request. The server sends an HTTP response to the client

As can be seen from the figure, cookie technology has four components:

  • 1. One of the HTTP response packetscookieThe first line
  • 2. One of the HTTP request packetscookieThe first line
  • 3. Reserve one in the client systemcookieFile and is managed by the user’s browser
  • 4. A back-end database located on a Web site

That said, cookie functionality requires browser support. If the browser does not support cookies (as is the case on most mobile phones) or has cookies disabled, the cookie function is disabled.

2. Cookie modification and deletion

When modifying the cookie, only the new cookie overwrites the old cookie. When overwriting, because the cookie can not cross the domain name, pay attention to the name, path and domain need to be consistent with the original cookie. Cookie deletion is the same. Set expires to a point in time in the past or maxAge to 0(the cookie validity period in seconds)

3. Cookie security

In fact, the use of cookies is controversial because it is considered a violation of user privacy, and cookies are not secure. The HTTP protocol is not only stateless, but also insecure. Data using HTTP protocol is transmitted directly on the network without any encryption and may be intercepted. The use of HTTP to transfer highly confidential content is a hazard.

  • If not,CookieFor transmission over non-secure protocols such as HTTP, cookies can be setsecureProperties fortrue. Browsers transmit such cookies only over secure protocols such as HTTPS and SSL.
  • In addition,secureProperty does not encrypt the Cookie content and therefore cannot be guaranteed absolute security. If high security is required, the Cookie content needs to be encrypted and decrypted in the program to prevent leaks.
  • You can also set itcookieforHttpOnlyIf set in the cookieHttpOnlyProperty, which will not be read by the JS scriptcookieInformation, this can effectively prevent **XSS (cross-site scripting attacks) ** attacks

Second, the Session

In addition to cookies, sessions are often used in Web applications to record client state. Session is a mechanism used by the server to record the state of the client. It is simpler to use than Cookie, but it also increases the storage pressure of the server.

Sessions are another mechanism for recording a client’s state, except that cookies are stored in the client’s browser and sessions are stored on the server. When the client browser accesses the server, the server records the client information in some form on the server. So this is Session. The client browser only needs to look up the state of the client from the Session when it accesses the Session again.

As shown in figure:

  • When an application needs to create one for a client requestsessionThe server first checks to see if the client’s request contains onesessionIdentification (calledSessionId)
  • If included, it has been previously created for this clientsession, the server will followSessionIdTo put thissessionIf you can’t retrieve it, you’ll create a new one.
  • If the client request does not containSessionId, create one for this clientsessionAnd generate one with thissessionThe associatedSessionId.SessionIdThe value of should be a string that is neither repeated nor easy to find patterns to mimic, this oneSessionIdWill be returned to the client for saving in this response.
  • Save thisSessionIdCan be adoptedcookieIn this way, the browser can automatically send the identity to the server in accordance with the rules during the interaction. butcookieCan be artificially prohibited, then there must be some other mechanism in order tocookieCan still be banned whenSessionIdPass it back to the server.

Cookie and Session

1. Cookie data is stored in the client’s browser, while session data is stored on the server.

2. Cookie is not very secure compared to session. Others can analyze the cookie stored locally and cheat the cookie.

3. The session is saved on the server for a certain period of time. Cookies should be used to reduce server performance when access increases.

4, a single cookie can not save more than 4K data, many browsers limit a site to save a maximum of 20 cookies. Sessions are stored on the server and can be stored in unlimited quantities

5. Therefore: Store important information such as login information as session; Other information, if needed, can be placed in cookies

—– IP protocol, IP datagram fragmentation, IPv4 addressing, network Address Translation (NAT)

Above the transport layer is the network layer. The network layer is responsible for the generation of IP packets and the routing and forwarding of IP packets on the logical network. The network layer is divided into three components:

  • 1. IP protocol
  • Routing protocol, which determines the path that a datagram takes from the source to the destination
  • Internet Control Message Protocol (ICMP), a device that reports errors in datagrams and responds to certain network layer information requests.
The difference between the network layer and transport layer
  • The network layer only transmits the packets sent from the source node to the destination node (point-to-point) according to the network address. Its main task is to select the most appropriate path for the packets or packets through the communication subnet through the routing algorithm. This layer controls the forwarding of information between the data link layer and the transport layer, and establishes, maintains and terminates network connections. Specifically, data link layer data is converted into packets at this layer, which are then transmitted from one network device to another through the control of path selection, segment combination, sequence, entry/exit route, etc.
The network layer provides logical communication between hosts
  • The transport layer, which provides end-to-end services between host application processes, is responsible for reliably transferring data to the appropriate ports (end-to-end). The transport layer makes use of the services provided by the network layer and provides the communication ports for high-level users to transmit data through the transport layer address, so that high-level users can only see an end-to-end, user-controlled and configurable, reliable data path between the two transport entities.
That is, the transport layer provides logical communication between processes running on different hosts

I. IP protocol

IP is the core protocol of TCP/IP.

1, IP protocol datagram format (IPv4)

  • The version number specifies the IP protocol version (IPv4 or IPv6) of the datagram. Different IP versions use different datagram formats. The figure above shows the IPv4 datagram format

  • Header length Most IP datagrams do not contain options, so a typical IP datagram has a 20-byte header.

  • The service type distinguishes different TYPES of IP datagrams from each other.

  • Datagram Length Length of the entire IP datagram. The starting address of the data content in the IP datagram can be calculated using the header length and the total length. The field is 16 bits long, so IP datagrams can be up to 2^16=65535 bytes, and in fact, datagrams rarely exceed 1500 bytes

  • The id, mark, and slice offset fields are related to IP fragments. In addition, IPv6 does not allow fragmentation of packets on routers

  • TTL is used to ensure that datagrams do not loop around the network forever. Sets the maximum number of routers that the datagram can pass through. When this field is 0, the datagram is discarded. When this field is 0, the datagram is discarded

  • Protocol This field is only useful when an IP datagram reaches its destination. The value of this field indicates to which specific transport layer protocol the data portion of the IP datagram should be handed over; for example, a value of 6 indicates TCP, and a value of 17 indicates UDP

  • Header validation and Unlike UDP/TCP validation, this field validates only the header of a datagram, not the data portion.

  • The option field is a variable length field, and the option field is always bounded by 4 bytes. This ensures that the header is always a multiple of 4 bytes. Rarely used

  • Source IP address and destination IP address

Record the source IP address and destination IP addressCopy the code
  • data

IP datagram fragments

The maximum amount of data that a link layer frame can carry is called the Maximum Transmission Unit (MTU). The MTU at the link layer limits the length of IP datagram. The problem is that different link layer protocols may be used on different links, and each protocol may have a different MTU. Suppose that an IP datagram is received on a certain link, and the outbound link is determined by checking the forwarding table, and the MTU of the outbound link is smaller than the length of the IP datagram. How to compress the oversized IP datagram into the payload field of the link layer frame?

The solution is fragmentation: the data in an IP datagram is fragmented into two or more smaller IP datagrams, the smaller IP datagrams are encapsulated in separate link-layer frames, and the frames are then sent to the outbound link. Each of these smaller pieces of data is called a fragment.

The chip needs to be reassembled before reaching its destination transport layer.

In fact, both TCP and UDP expect to receive complete, unfragmented packets from the network layer. The job of IPv4 datagram reassembly is in the end system, not in the network router. When a destination host receives a set of data from the same source, it needs to determine whether some of these datagrams are slices in some previously larger datagrams. In the case of slices, you need to further determine when the last piece will be received and how the pieces will be spliced together to form the initial datagram. This is where the id, flag, and chip offset fields in the IPv4 datagram header mentioned earlier are used.

  • 1. When a datagram is generated, the sending host is setting for the datagramSource and destination IP addressesAt the same time in the pasteId no., the sending host will normally send each datagram for itId no.Add 1
  • 2. When a router needs to fragment a datagram, each datagram (that is, slice) formed has the initial datagramSource address,The destination addressandId no.
  • 3. When a destination receives a series of datagrams from the same sending host, it can check the datagram’sId no.To determine which datagrams are actually slices of the same larger datagram
  • 4. Because THE IP protocol is an unreliable service, one or more slices may never reach their destination. In order to make the destination host absolutely confident that it has received the last slice of the initial datagram, the last slice of theSign bitIs set to 0, and the rest is set to 1
  • 5. In order for the destination host to determine whether a chip is missing and to reassemble the chip in the correct order, useThe offset fieldSpecifies where the slice should be placed in the initial IP datagram > In addition, if one or more slices fail to arrive, the incomplete datagram will be discarded and will not be delivered to the transport layer. But if the transport layer is using TCP, TCP will retransmit the data by having the source use the original data. Because there is no timeout retransmission mechanism at the IP layer, the entire datagram is retransmitted, not a slice

IPv4 addressing

1. IP address

A host usually has only one link connected to the network, and when an IP address on the host wants to send a datagram, it sends it on that link. The boundary between a host and a physical link is called an interface. A router must have two or more links connected to it. The boundary between a router and any one of its links is also called an interface. That is, a router has multiple interfaces, and each interface has its own link. Because each host and router can send and receive IP datagrams, IP requires that each host and router interface have its own IP address. Thus, an IP address is technically associated with an interface, not with the host or router that includes the interface.

2, subnet

Each IP address (IPv4) is 32 bits (4 bytes) in length and is written in dotted decimal notation. That is, each byte in the address is written in decimal notation with dots between each byte. For example, 193.32.122.30 Each interface on each host and router on the Internet must have a globally unique IP address (except for NAT interfaces). These addresses are not freely selected; a portion of an interface’s IP address is determined by the subnet to which it is connected.

As shown in the picture, a router has three interfaces that connect to seven hosts. The interfaces of the three hosts on the left, and the routers that connect to them, have an IP address in the form of 223.1.1.x. In their IP addresses, the leftmost 24 bits are the same.

Interconnection The three host interfaces on the left and the network of one router interface form a subnet (also known as an IP network or directly as a network). The IP address assigns the subnet an address: 223.1.1.0/24, where the /24 notation, sometimes called the network mask, indicates that the leftmost 24 of the 32 bits define the subnet address. Any host connected to this subnet requires its address to be of the form 223.1.1.x. The lower and right sides of the figure are also subnets, 223.1.3.0/24 and 223.1.2.0/24 respectively

The figure above shows three routers connected to each other through a point-to-point link, with six subnets present. An organization with multiple Ethernet segments and point-to-point links will have multiple subnets, with all devices on the stator network having the same subnet address. In theory, though, different subnets can have completely different subnet addresses. But as you can see from the figure above, these 6 subnets are consistent in the first 16 bits, all 223.1

3. Classless Inter-domain Routing (CIDR)

The address assignment policy for the Internet is known as classless Interdomain routing (CIDR) (also known as classless addressing to distinguish it from classless addressing). For subnet addressing, a 32-bit IP address is divided into two parts, A.B.C.D /x in dotted decimal notation. X indicates the number of bits in the first part of the address, which is also called the prefix. An organization is usually assigned a contiguous block of addresses, that is, addresses with the same prefix. Routers outside the organization only consider the preceding prefix bit x, which considerably reduces the length of the forwarding post in these routers in the form A.B.C.D /x a single entry is sufficient to forward the datagram to any destination within the organization.

As shown in the figure, there are eight organizations under 200.23.16.0/20, 200.23.16.0/23 to 200.23.30/23, and each organization has its own subnet. The outside world doesn’t need to know about these eight organizations. This ability to advertise multiple networks using a single network prefix is often referred to as address aggregation, also known as route aggregation or route summary

4. Classification addressing

Before CIDR was adopted, the network parts of IP addresses were limited to 8, 16, and 24 bits in length, known as classful addressing. Subnets with 8, 16, and 24 bit subnet addresses are referred to as Class A, B, and C networks. A class C (/24) subnet can accommodate ***2[Image -448ab4-1627110540448]

  • 2 = 254*** hosts (with two addresses reserved for special purposes), which is too small for many organizations.

While a Class B (/16) subnet can support up to ***2

  • 2 = 65534*** host, and too big.

Under classified addressing, an organization with 2000 hosts is typically assigned a Class B (/16) address, and the remaining 60,000-plus addresses are wasted. This leads to rapid depletion of the Class B address space and low utilization of the allocated address space.

In addition, 255.255.255.255 is an IP broadcast address. When a host sends a datagram destined for this address, the datagram is delivered to all hosts on the same network.

5. Obtain the host address

Once an organization obtains an address, it can assign IP addresses to hosts and routers in the organization one by one. The system administrator usually manually configures the IP address of the router. Host addresses can also be manually configured, but dynamic Host Configuration Protocol (DHCP) is more commonly used. DHCP allows hosts to automatically obtain IP addresses. The network administrator can configure DHCP so that a given host will get the same IP address each time it connects to the network, or a host will be assigned a temporary IP address, which may be different each time it connects to the network.

6. Network address translation

Each IP address (IPv4) is 32 bits (4 bytes) long, so there are a total of 2[image upload failure…

One possible IP address, about four billion. With the increasing popularity of the Internet and the increasing number of personal computers and smart phones, these IP addresses are clearly not enough to meet people’s needs. In order to solve the problem of insufficient IP addresses, Network Address Translation (NAT) was developed. The idea is to assign an IP Address to a local area Network. For the hosts in the Network, private addresses are assigned, which are not visible to the outside. They communicate with each other through that uniquely assigned IP address.

If all datagram from the WAN to the NAT router have the same destination IP address, how does the router know which internal host it is sending to? The principle is a NAT table used on the NAT router, and the table contains the port number and IP address.

Assume that a host requests data from a wan. After receiving the datagram, the NAT router generates a new port number for the datagram instead of the source port number, and replaces the source IP address with the IP address of its WAN interface. When to generate a new source port, the port number can be any one not currently in the NAT translation table source port (port number field is 16 bits, means NAT protocol can support more than 60000 concurrent use the IP address of the router wan side connection), the router NAT also added a table in the NAT translation table.

When the NAT router receives the data returned by the WAN, it retrieves the IP address and destination port number of the host from the NAT table using the destination IP address and destination port number, changes the destination IP address and destination port number of the datagram, and forwards the datagram to the host

Although NAT has been widely used in recent years, it is also opposed by many people. Main is:

  • 1. Port numbers are used for process addressing, not host addressing. (The NAT protocol is similar to the NAT router, which treats hosts on the home network as processes and assigns port numbers to them through the NAT table.)
  • Routers should normally only process packets up to layer 3
  • 3. It violates the end-to-end principle, that is, hosts should talk to each other directly, and nodes should not intervene to change IP addresses and port numbers.
  • 4. IPv6 should be used to solve the IP address shortage problem

But against or against, NAT has become an important component of today’s Internet

IOS interview question —– Network-related IPv6 and migration from IPv4 to IPv6

IPv6 was created to solve the problem of running out of 32-bit IPv4 address space as new subnets and IP nodes were connected to the Internet at an alarming rate and assigned unique IP addresses. In fact, more than 20 years ago, the Internet Engineering Task Force began working on an alternative to IPv4, known as IPv6

1. IPv6 datagram format

1. IPv6 datagram format

  • Version (4 bits) This field identifies the IP version number. In IPv6, the value of this field is set to 6. Setting this field to 4 does not create a valid IPv4 datagram

  • Traffic type (8 bits) Similar to service Type (TOS) in IPv4 datagrams

  • Stream Tag (20 bits) A stream tag field is a new field in IPv6 datagrams. It identifies the stream type of a datagram and distinguishes packets at the network layer.

  • Payload length (16 bits)

In an IPv6 datagram, the number of bytes after the header of the datagram with a fixed length of 40 bytes is the total length of all the parts except the header of the IPv6 datagram

  • Next header (8 bits) When IPv6 does not have an extended header, this field serves the same function as an IPv4 protocol field. When an extension header is included, the value of this field is the type of the first extension header

  • Hop limit (8 bits) Similar to the TTL field in aN IPv4 packet, each router that forwards the datagram deducts the content of this field by 1. If the hop limit count reaches 0, the datagram is discarded

  • Source IP Address and Destination IP Address (128 bits each) Indicates the source IP address and destination IP address

  • data

As you can see, several fields that appear in the IPv4 datagram no longer exist in the IPv6 datagram:

  • Fragment/reassembleIPv6 does not allow fragmentation and reassembly on intermediate routers. This operation can only be performed on the source and destination sites. If an IPv6 datagram received by a router is too large to be forwarded to the link, the router dismisses the datagram and sends back an ICMP error packet with a too-large packet
  • Head check sumBecause the transport layer and data link layer protocols perform validation, this function is not necessary at the network layer, resulting in faster processing of IP packets
  • optionsThe options field is no longer part of the standard IP header. Instead of disappearing, it may appear in the location indicated by the “next header” in the IPv6 header. That is, just as the TCP or UDP header can be “next header” in an IP packet, the options field can also be “next header”.

The most important changes to IPv6 over IPv4 are as follows:

  • Expanded address capacity IPv6 increases the length of IP addresses from 32 bits to 128 bits, increasing the number of theoretically available IP addresses to 2.

    , about 340 trillion, this is a very big number, make sure that the world will never run out of IP addresses, even for every grain of sand on the earth are assigned a unique IP address Besides unicast and multicast addresses, IPv6 is not broadcast this claim, but introduced a known as the new address of the multicast address, This address enables the datagram to be delivered to any host in a group

  • Simplified and efficient 40-byte header Except the 32-byte source address and target address, the other fields in the header only occupy 8 bytes

  • Stream labels and priorities label groups that belong to special streams that the sender requests special processing, such as a non-default quality of service or streams that require real-time service

2. IPv6 writing and expression

The 128-bit IPv6 address is divided into eight 16-bit binary segments. Each 16-bit binary segment is represented by a four-bit hexadecimal number and separated by colons (:). The writing method of the 128-bit IPv6 address is the same as the decimal number of the IPv4 address plus a comma (“). Different).

For example: 1000, 0000:0000-0000:000 a: 000 b: 000 c: 000 d is a 16 bit binary number of segments with four hexadecimal number to represent, paragraphs with a “:” (colon) between an IPv6 address; Where: Each 4-bit hexadecimal number in the segment of the high 0 is allowed to omit; Therefore, the IPv6 address above can also be abbreviated to: 1000:0:0:0:A:B:C:D.

To further simplify things, the IPv6 address specification also states, ** in an IPv6 address, double colons (::) ** can be used at most once to replace the closely connected hexadecimal digits with all zeros. If double colons are allowed to be used more than once in an IPv6 address, the length of an IPv6 address cannot be determined. Therefore, the IPv6 address specification specifies that: You can use the double colon at most once in an IPv6 address. In this way, the above IPv6 address can be abbreviated as: 1000::A:B:C:D.

The double colon can be placed before, after, or in the middle of an IPv6 address. For example, the IPv6 address 1000:0:0:0:A:B:0:0 can be written as 1000::A:B:0:0 or 1000:0:0:0:A:B::. But it cannot be written as 1000::A:B::.

The IPV6 address with a port number is a string of characters. The address must be enclosed in brackets ([]), followed by a hyphen (:) and an upper number, for example, [A01F::0]:8000

Migration from IPv4 to IPv6

How does an ipv4-based public Internet migrate to IPv6? This is a very real problem. While ipv6-enabled systems can be backwards-compatible, that is, capable of receiving, sending, and routing IPv4 datagrams, deployed ipv4-enabled systems cannot handle IPv6 datagrams

1. Dual protocol stack

The most direct way to introduce IPv6 enabled nodes is the dual-stack method, that is, IPv6 nodes using this method also have a full IPv4 implementation, namely IPv6/IPv4 nodes, with the ability to receive and send both IPv4 and IPv6 datagrams. When interoperating with IPv4 nodes, IPv6/IPv4 nodes can use IPv4 datagrams. When interoperating with IPv6 nodes, IPv6/IPv4 nodes can also use IPv6 datagrams.

IPv6/IPv4 Nodes must have both IPv6 and IPv4 addresses. In addition, they must be able to determine whether another node is IPv6 enabled or only IPv4 enabled.

DNS can be used to resolve the problem. If the node name to be resolved is IPv6 enabled, DNS returns an IPv6 address, otherwise an IPv4 address is returned. If only IPv4 is enabled for the node making the DNS request, only one IPv4 address is returned.

Two IPv6 enabled nodes should not send IPv4 datagrams to each other. If either the sender or the receiver is enabled only with IPv4, IPv4 datagrams must be used. This leads to the following:

As shown in the figure, if nodes A, B, E, and F are all IPv6 enabled, and nodes C and D are only IPv4 enabled, then when data packets are sent in the order A->B->C->D->E->F, IPv6 datagram will be sent between AB and IPv4 datagram will be sent between BC and IPv6 datagram will be sent. Because the IPv6 datagram specific fields do not have corresponding sections in the IPv4 datagram, these fields will be lost. Thus, even if aN IPv6 datagram can be sent between E and F, the IPv4 datagram from D to E does not contain all the fields from the original IPv6 datagram sent from A.

2, tunnel

Tunneling is another dual stack method that can solve this problem. Suppose two IPv6 nodes want to interact using IPv6 datagrams, but they are connected via an intermediate IPv4 router. The IPv4 routers between the two IPv6 routers are combined into a tunnel, for example, B->C->D->E.

As shown in the figure, with the help of the tunnel, the IPv6 node at the transmitting end of the tunnel can put the entire IPv6 datagram into the data field of an IPv4 datagram. The IPv4 datagram is then addressed to the IPv6 node at the receiving end of the tunnel and sent to the first node in the tunnel. The IPv4 router in the tunnel routes the datagram between them, just like any other IPv4 datagram, without knowing that the datagram itself contains a full IPv6 datagram. The IPv6 node at the receiving end of the tunnel finally receives the IPv4 datagram, determines that the IPv4 datagram contains an IPv6 datagram, extracts the IPv6 datagram, and then provides a route for the IPv6 datagram

3, NAT – PT

In addition to dual-stack and tunneling schemes, there is a Network Address Translator scheme with a Protocol Translator (NAT-PT)

Portal: iOS Interview Materials)