Why Ask About TCP/IP/HTTP Protocols in Interviews?

What else can we ask if we don’t ask about these protocols? Should we ask about OSPF or BGP? Those are protocols used by network engineers. Should we ask about Kerberos or CIFS/SMB? Those are protocols used by Windows system administrators. Should we ask about Access Tokens, SSO, CSRF, or SQL Injection? Those are concepts used in web development. Should we ask about rainbow tables, Padding Oracle, Crime, or Beast? Those are topics relevant to information security. Only TCP/IP/HTTP is the common intersection for all four types of professionals, as TCP/IP/HTTP accounts for the vast majority of internet traffic. Internet professionals need to learn these foundational skills just like learning to read and write. Here are some basic interview questions: 1.If both parties in a TCP connection send SYN signals simultaneously, will a TCP connection be established, or will there be two TCP connections? The interviewee has learned from textbooks that TCP uses a three-way handshake. Since both parties send SYN signals simultaneously, there will be two sets of three-way handshake messages, ultimately resulting in two TCP connections. Let’s look at an example.Alice‘s IP = 6.6.6.6, Listening Port = 6666, Bob’s IP = 8.8.8.8, Listening Port = 8888 Scenario 1: The initiating connection uses the listening port as the source port Alice sends a SYN signal, the packet looks like this:

Bob sends a SYN signal, the packet looks like this:

The four tuples of both parties match perfectly, and they are moving towards each other on the same track, so they will eventually meet and establish a connection. Unlike the traditional TCP three-way handshake, this requires four message exchanges, and both parties need to use SYN + ACK packets to confirm each other. Scenario 2: The initiating connection uses a random port as the source port Alice sends a SYN signal, the packet looks like this:

Bob sends a SYN signal, the packet looks like this:

The four tuples of both parties do not match, and both need to use SYN + ACK to respond to each other, completing the TCP connection with a full three-message exchange, resulting in two TCP connections being established. The question arises: which connection will be used to transmit data? Any one can be used, but the other idle TCP connection is a waste of resources! However, TCP does not know that this is a resource waste, but the application does know that TCP has helped establish two virtual TCP channels, and the application needs to make a choice! How does the application make a choice?BGP protocol runs on TCP port 179, and in scenario two, two TCP connections are inevitably established. BGP completes the BGP state machine transition on one of the TCP connections: connect, active, established. Once established, BGP considers this TCP connection to be valid and immediately instructs TCP to release the other idle TCP connection. 2Why does the active closing party need to wait for 2MSL time before releasing port resources?The active closing party’s last ACK message cannot ensure it reaches the other party if the port resources are released immediately.When the four tuples of the newly established TCP connection are exactly the same as the recently closed four tuples, at this moment, the FIN packet of the old TCP connection may just arrive, and if theSequence Number is within the valid receiving window of the new TCP connection, the new connection is very likely to be closed. Theoretically, the maximum survival time of an IP packet on the network is 255 seconds (TTL=255). If the active closing party waits for 255 seconds, the TCP packets lingering on the network will either reach the active closing party or be discarded by the network, disappearing from the network forever. This is a consideration from the network perspective. If the passive closing party does not receive the ACK from the active closing party, it will keep retransmitting the FIN, with the retransmission time cycle generally being: 0.5, 1, 2, 4, 8, 16, 32, 32 After 8 retransmissions without receiving the other party’s ACK, the passive closing party will reset the current connection. Considering the time of the last retransmission message and the possible time lingering on the network, the combination of these two factors leads the TCP protocol specification to decide that the passive closing party needs to wait for 240 seconds, while MSL = 120 seconds. The waiting time for the passive closing party = 2MSL. This TCP regulation is actually a response to extreme situations where data from two TCP connections may conflict!