We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

TCP / IP Animated

00:00

Formal Metadata

Title
TCP / IP Animated
Title of Series
Number of Parts
160
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
TCP / IP Animated [EuroPython 2017 - Interactive session - 2017-07-10 - PythonAnywhere Room] [Rimini, Italy] This interactive game teaches is the follow-up of the Router Game by Roberto Polli, and teaches various TCP / IP protocols using paper and pen. Participants are divided in teams, simulating exchanges through various protocols (DNS, TCP, IP) Every player has an L3 role: a PC or mobile phone, a Router, a Load Balancer ... and must communicate with the others following the associate specification (eg. a TCP client may buffer frames, a Load Balancer re-encapsulates IP datagram, ... ) The team which is faster in exhanging messages wins
SoftwareDemonIntelGame theoryConnected spaceFlagIP addressInterprozesskommunikationNetwork topologyComputer animationMeeting/Interview
AreaSoftwareNetwork topologyGame theoryFeedbackMultiplication signRouter (computing)Local area network
EncryptionStructural loadPlastikkarteAddress spaceGame theoryGoodness of fitProof theoryInteractive televisionCountingWeb pageEncapsulation (object-oriented programming)Speech synthesisInformationLecture/Conference
IPPhysical systemCoding theoryVisualization (computer graphics)OracleSystem administratorVertical directionJava appletService (economics)Business IntelligenceDynamic Host Configuration ProtocolInterface (computing)Computer networkServer (computing)Error messageInterprozesskommunikationRight angleMereologyWeightSoftwareWritingInterface (computing)Adventure gameServer (computing)Computer animation
Dynamic Host Configuration ProtocolComputer networkInterface (computing)Server (computing)InterprozesskommunikationError messageData modelPresentation of a groupRing (mathematics)Token ringLink (knot theory)Bridging (networking)Router (computing)WindowInformationConnected spaceServer (computing)Social classInterprozesskommunikationClosed setSource codeError message
Presentation of a groupFile Transfer ProtocolUDP <Protokoll>Router (computing)Asynchronous Transfer ModeToken ringRing (mathematics)Bridging (networking)Data modelSoftwareLink (knot theory)Cartesian coordinate systemCommunications protocolTelnetInformationPropagatorProgram flowchart
Token ringRing (mathematics)Data modelPresentation of a groupFile Transfer ProtocolBridging (networking)Link (knot theory)Router (computing)Computer networkRandom numberSpywareInternetworkingInterprozesskommunikationNumberSequenceHill differential equationTopologyIP addressNetwork topologyMultiplication signSpywareInterprozesskommunikationLocal area networkNumberConnected spaceSequenceCommunications protocolRandomizationPhysical systemProduct (business)Slide ruleDistanceData transmissionDivision (mathematics)
TopologyRootBitGradientComputer animationLecture/ConferenceMeeting/Interview
TopologyTelnetServer (computing)Computer networkMessage passingNetwork topologySoftwareHacker (term)Connected spaceAreaProcess (computing)Goodness of fitMessage passingRule of inferenceRouter (computing)Client (computing)Musical ensembleArithmetic meanTelnet
Server (computing)TelnetComputer networkMessage passingRouter (computing)TelnetConnected spaceServer (computing)Office suiteBitRootMassSource codeCompilerError messageFormal grammarBit rateSpeech synthesisInformationAddress spaceEmailComputer animationLecture/Conference
Repeating decimalRule of inferenceEmailIn-System-ProgrammierungOperator (mathematics)Hand fanMaxima and minimaGame theoryClient (computing)Source codeMereologyFormal grammarDemosceneClient (computing)Flow separationRandom number generationSynchronizationSlide ruleSoftware testingInterprozesskommunikationInternet forumFlagServer (computing)Computer animationProgram flowchart
Electronic meeting systemGame theoryClient (computing)MereologyNetwork topologyTwitterSource codeTelnetWritingDependent and independent variablesFlagHacker (term)ResultantProgram flowchartComputer animation
Game theoryClient (computing)Information managementCommunications protocolInformationSpacetimeRight angleTheoryMultiplication signAreaNumberArithmetic meanComputer animationProgram flowchart
Game theoryClient (computing)SimulationMessage passingServer (computing)Position operatorSlide ruleClient (computing)WeightLecture/ConferenceProgram flowchart
Game theoryClient (computing)SimulationServer (computing)TelnetQuicksortSoftwareCASE <Informatik>Connected spaceState of matterGame theoryTelnetDemosceneServer (computing)Source codeClient (computing)MereologyMessage passingMechanism designArithmetic meanFrequencyService (economics)TheoryMultiplication signPoint (geometry)Wave packetSound effectArmWindowTwitterClosed setSet (mathematics)Meeting/InterviewProgram flowchart
Client (computing)TelnetServer (computing)Data miningGame theorySalem, IllinoisOpen setSimulationSineRight angleTelnetEvent horizonNumberVector spaceSequenceFeedbackEmailIntegerMultiplication signField (computer science)Source codeComputer animation
Game theoryServer (computing)Client (computing)TelnetNumberSequenceServer (computing)TelnetDependent and independent variablesParameter (computer programming)InformationString (computer science)Order (biology)MetreTerm (mathematics)Slide ruleInsertion lossComputer animation
Client (computing)Server (computing)TelnetLevel (video gaming)FlagNumberServer (computing)FeedbackClient (computing)DivisorHacker (term)InformationConnected spaceEvent horizonTelnetComputer animationLecture/Conference
Server (computing)TelnetData miningClient (computing)NumberSequenceServer (computing)InterprozesskommunikationGame theoryCASE <Informatik>Client (computing)Online helpRobot
Server (computing)TelnetClient (computing)Electronic meeting systemServer (computing)SequenceNumberState of matterAddress spaceConnected spaceExecution unitStreaming mediaDifferent (Kate Ryan album)HypermediaClient (computing)IP addressSynchronizationFluxLecture/ConferenceMeeting/Interview
Connected spaceVirtual machineKernel (computing)Mechanism designStructural loadBitServer (computing)Semiconductor memoryData managementComputer-assisted translationProxy serverLetterpress printingPatch (Unix)Natural languageBeat (acoustics)Revision controlLecture/Conference
Data miningTelnetServer (computing)NumberClient (computing)Service (economics)Connected spaceCASE <Informatik>Decision theoryRootMechanism designServer (computing)Right angleSPARCMereologyRouter (computing)Stress (mechanics)Electric generatorFlag
Server (computing)TelnetData miningServer (computing)Web 2.0CASE <Informatik>Firewall (computing)Network topologyPhysical systemIP addressDifferent (Kate Ryan album)Connected spaceFlagMereologyInformationWeightSystem callDiscounts and allowancesMeeting/Interview
Client (computing)TelnetServer (computing)Data miningComputer networkSoftwareNetwork topologyClient (computing)Firewall (computing)MereologyDependent and independent variablesServer (computing)InterprozesskommunikationConnected spaceInheritance (object-oriented programming)Drop (liquid)Physical systemSource codeVirtual machineLecture/ConferenceComputer animation
Client (computing)Server (computing)MereologyMatching (graph theory)NumberRandomizationString (computer science)SynchronizationSource codeDrop (liquid)Right angleDependent and independent variablesFlagStreaming mediaExistenceLecture/ConferenceMeeting/Interview
TelnetServer (computing)RootResolvent formalismRouter (computing)Interface (computing)DampingError messageSource codeRoutingAddress spaceServer (computing)
Host Identity ProtocolServer (computing)TelnetClient (computing)Computer networkGame theorySystems engineeringSimulationTable (information)Error messageInterface (computing)RootFreezingWordTelnetCommunications protocolServer (computing)Client (computing)Router (computing)SoftwareInformationDampingWindowGroup actionLevel (video gaming)Connected spaceWeb pageWeightRule of inferenceLink (knot theory)KinematicsDifferent (Kate Ryan album)Lecture/Conference
Computer networkRight angleRoutingSoftwareRouter (computing)RootLecture/ConferenceComputer animationMeeting/Interview
Computer networkCorrelation and dependenceClient (computing)Game theoryServer (computing)Information managementOpen setSimulationServer (computing)SoftwareDifferent (Kate Ryan album)Point (geometry)Computer animationMeeting/Interview
SimulationServer (computing)Game theoryClient (computing)Open setMaxima and minimaSoftwareField (computer science)Level (video gaming)Server (computing)Table (information)Client (computing)MappingRoutingConnected spaceRouter (computing)Boom (sailing)Address spaceReading (process)DemosceneMereologyComputer animation
Client (computing)Server (computing)Game theoryDataflowMatching (graph theory)SoftwareProjective planeServer (computing)Firewall (computing)Connected spaceRoutingCommunications protocolHacker (term)Different (Kate Ryan album)Game theoryRootSimilarity (geometry)Meeting/InterviewProgram flowchart
Normal (geometry)Information managementMilitary operationSimulationElectronic meeting systemGame theoryMetropolitan area networkBuffer solutionAlgorithmClient (computing)Connected spaceCASE <Informatik>MiniDiscMultiplication signMessage passingDependent and independent variablesModal logicFlagSound effectPower (physics)Error messageWeightSheaf (mathematics)Server (computing)Rule of inferenceLine (geometry)PlanningState of matterService (economics)Closed setHacker (term)RootDirection (geometry)BitOpen setComputer animationProgram flowchart
SimulationClient (computing)MereologyMultiplication signCASE <Informatik>Data transmissionServer (computing)Pattern languageMeeting/InterviewComputer animationProgram flowchart
SimulationNormal (geometry)Maxima and minimaMultiplication signConnected spaceNetwork socketClient (computing)QuicksortEntropie <Informationstheorie>CASE <Informatik>Source codeMereologyPattern languageResultantServer (computing)Arithmetic progressionProxy serverWeightArithmetic meanComputer animationMeeting/InterviewProgram flowchart
Information managementSimulationMaxima and minimaProxy serverServer (computing)Process (computing)Service (economics)Address spaceSoftwareConnected spaceWeightMultiplication signFirewall (computing)Software testingConfiguration spaceMechanism designNetwork socketLocal ringLastteilungStress (mechanics)Integrated development environmentSocket-SchnittstelleComputer animationProgram flowchart
Formal grammarElectronic meeting systemRegular graphIntegrated development environmentPoint (geometry)TunisTheoryMultiplication signComputer animation
Transcript: English(auto-generated)
Hello, everybody, welcome to Europe-ython. We are going to attend a wonderful interactive session, and it is a game with pen and paper, showing a basic communication with TCP.
So we will see how a connection is established and how is it closed. Everything is interactive, so you're gonna write down IP addresses and checking TCP flags on small flyers.
You should form three or four people teams, and every three or four people is a small local area
network connected to a hub switch or router. The talk is presented by Danilo Bashano. He's a first-time speaker,
so I hope to welcome him warmly. And it is the first time that he makes this TCP IP game, so your feedback to make it grow and to make it better is really appreciated, so next year we could do
even more and more complex stuff, like load balancing, encapsulation, and so on. Encryption. Encryption. Last year, we made a game with Mac addresses
and basic getaways, and people enjoyed a lot, and somebody came asking if I was delivering a package with all the cards of the games, but, well, let's start now.
Danilo speaking, I will try to help him when needed. Good luck, Danilo. Thank you, Roberto, Pauli. So this is a TCP IP animated interactive session.
You can touch the packet that will transmit on the network and write on paper
and simulate how this packet travel on the net. I am Danilo Bashano, and I work in a company, Partang, that sponsored this talk.
And Roberto Pauli helped me to this adventure. So, we started to bring up network interfaces
with the DHP server, and this is the DHP server. First, we make the handshake. We see just the layer TCP and the IP.
Communicate some data. We introduce some communication error to, this is what we will see. And then, at last, say goodbye with closing connection.
This is just an overview of his source stack. It's divided by layer, and each layer are encapsulating information, one inside the next layer.
So, from Watson, it's the physical, it's how the PC are connected. So, the wired, or something else, data link, network and transport.
We will focus our attention in network layer with the protocol IP and transport layer with the TCP. Then, up of this layer, we have the application layer,
and for not introducing some information, some problematics, but other protocol, we choose the Telnet application. It's the simplest application.
We'll set the just to transmit byte. So, I leave Roberto Pauli, introduce him. Now, I start to give the... Danilo makes the DHCP server, providing your IP addresses and pants.
Please remember, you should form teams of four people. Every four people, it's a local area network. So, check your teammates and form your teams. What's essentially TCPP is...
TCPP provides the ability to have a reliable protocol. It introduce the connection concept. That means that me and you knows, before starting transmitting data, who we are.
This is something that is not provided by other protocols. So, with these writing packets, with pen and paper, we will understand why all those passages are important.
So, for every transmission, it happens, something that we see in war movies, like, okay, Roger Death, and then the other says, okay, Roger Death.
TCPP IP is something like radio communication during war movies between the surgeons and the chieftain. What we see is that after that,
TCPP IP provides a basic hijacking protection using random initial sequence number. That's something that we will see if we have time while we wrote packets. And that all these checks, all those in knowledge,
enables retransmissions. So, Danilo is providing you pens and paper. This is our basic topology. So, one of your team should be the router,
the one that enables other people to communicate. Please choose something that knows a bit of TCPP IP, but it's not compulsory. And then, okay, now I'm going to help you.
In making the teams. So, is there some team already made? Please raise your hand. Team one, who is team one? Okay, all your hands, team one, raise all your hands.
Please give you a name. Be doing yourself, chose a name. The same for the other teams. So, this is team two. Raise your hand, team two, okay?
Team two, just team two, would you? Okay, team two, wow. We are team Rimini. Team Rimini, great. Show me this team, I love you.
Big names. Bologna team. Bologna, okay, just like Spaghetti a la Bolognese.
Wonderful. Name router switch. Router switch, wow, great.
Just watching, okay, wonderful. No problem, you can join whenever you want. It's just something like plugging another device in. Okay, another standby device.
Excuse me?
Yeah, but you can't have a router if you're not a switch. Yeah, for this setup, as they just have an IP, they must be connected to something that is L2 enabled.
So, we couldn't have root, just router. Okay, as the packets are, well, not many,
you can reuse them. Maybe for the first connection, you can use just one piece of paper and then move on, Benilo, it's up to you.
Okay, we just created some subnets in the topology like this, so we just are, one people is the router switch, it's the blue one,
and all the other people in the subnet are connected to the switch. The router have the happy ends with the two, five, four, and in every subnet, there are the dot one,
and he's the telnet server, and are listening on port 23. All others are the user, all right.
Okay, first goal is to make an handshake. Handshake is used to establish a TCP IP connection over an IP network. It's also called the three-way handshake because it's needed to transmit three messages.
First one is SYN, the second one is from router to client, and it's called SYN hack, and the last one, hack. The name of the packet are the same name of Flex,
so we will explain later. The goal is a whole user will establish a connection to the telnet server, every packet must go firstly
to the router switch, then to the server. This is just a datagram of IP header. The information that we use in this speech
is the source address and the destination addresses. So you have to compile the packet with the source and destination. The other part of packet is the TCP datagram,
and we have to use 23 as the destination port. With source ports, you can write a random number, and we use also TCP Flex and data for transmit data.
In this slide, you can see the handshake communication between the client and server. Client sends the first packet when the flag SYN is checked.
SYN is for synchronization. I mean, I want to start a synchronization with you. So you can start to write source IP, destination IP, SYN flag, and 23 as the destination port.
To the telnet server, then the telnet server, the people that have the IP with one
have to respond with another packet with the SYN and hack flagged.
Okay, ready, set, go.
In the first packet, there is no hack, it's empty. I mean, it's not zero, it's zero bytes.
So it's zero? Yeah, but it's. It's not zero bytes because it's fixed? It's zero, yeah. So it's zero?
Yeah, it's not red on the protocol. Yeah, but the space is there? Yeah. Nothing, because it's the first one. All right, let's try. To the router? So I'm a router, I don't have any information
about the network, so I can't do anything. Okay, okay, but as we are in TCP, we think that, well, we simulate that you already have, I mean, we skipped the ERP. So I assume I've got a MAC table? Yeah, you do whatever is L2 in background.
You don't show them. Yes, okay, first exchange, done.
Okay, so you sent a scene, but you shouldn't have provided any data, because, okay, because it's the handshake. You don't know if it's him. You didn't already start at something, so you can't rely that the message
have been routed to the ERP destination. You might not even know that he exists. Okay, so what, just reuse blankets?
No, he should know. You're the server. So it's you that should send him. He has to wait, you are the server, you just received this, or you wrote it?
No, you should wait for packets to come to you. Okay, the telnet, well, it was in the previous slide. Actually, the client, the server is always the dot one.
Yes, whatever you got, dot one. Okay, yeah, the router get it, and he makes all the ERP stuff, and provides, okay, you are just, yeah?
In this case, you don't need to, you are on the same local network, you don't have next to. Because it's always on the same subnet.
You should, okay. Ah, you have a hate, ah, okay. Okay, okay, now you should have, it's, excuse me, you just put. Two eight, Alice fine now.
You should have had only one network, because the second part of the game is connecting the two routers, so you exchange packet with him? No, exactly, until you meet with him.
Okay, perfect, wonderful. So, okay, you, just the same? No, well, the port is 23. Yeah, because telnet is 23.
Okay, and you, so when you receive this packet, what happens, you should acknowledge, you set an ACK on that, perfect, and send them back.
You actually should write ACK as the source IP, but we have a very few packets. So we save it for this time, okay? Exactly, just use last octet.
Okay, that's it. Here, everything fine? Did you establish the connection?
Okay, you didn't have any, oh, very good. Can I see the first one? This was the scene. Another important.
I have a scenic messenger. Another important thing is the, as you showed, the client state and server state. Server starts with the closed door,
then where the telnet server comes up, the server are listening on the port 23. The client connection state firstly are closed.
Send the scene packet and become sent, and the server scene received. After end shake, when the end shake are completed,
the old client and server, both are in the established connection state. All right, we can go on.
So now the connection, now the connection is established and we can start to talk.
The message, the data messaging is my name is, and write your name. Send the packet with, yes, okay. Send the packet to the telnet server,
then receive the packet and come back a feedback with a package with the hack flag. So now I want to introduce another two fields.
The sequence number, acknowledge number. So the sequence number is just an integer when the start from zero and increment plus one
every time someone send a packet. Acknowledge number is another field in the TCP header to check if the packet are received well
or if there happened something wrong like lost data or packet loss. Sequence number is also used to,
if I receive the packet, not in order. So it's used to sort my response. In this slide, you can see the end shake, the end shake with the other two parameters set.
Now we have to send this information to the server telnet. The information is my name is Danilo
and start with the sequence number zero. The server telnet receive zero to 16 byte because the string my name is Danilo are 17 bytes.
Then the server receive a feedback to the client with the flag hack and the number of byte received, right? So this is possible to send information
only after the TCP IP connection is submitted.
At the end, the server telnet can know all your names.
Is it everything clear? For now, we are going to start with zero clearly for the game, but what happens is the first
sequence number is a random one because it helps to avoid other people introducing themselves in the communication and the first value of sequence of bot hosts are used just like a secret
between the client and the server. And well, we can start writing our first data packet containing my name is providing, try to provide a sequence and a knowledge number
in your communication. If you are not able, it's no problem. Just try to do it.
Someone needs some help.
So which is the packet that you received? Okay. So that's okay. Those are two different strings, two different connections. One from number one and two.
The other one is from number three and one. Every connection has its own stream and has its own flux of sequence and the knowledge.
Questions? So a question for all those Linux guys. Where are all those synchronization and a knowledge bytes, all those IP addresses stored in clients and servers?
Yeah, all those TCP data stored in the servers, in memory, exactly. So remember if your servers have to manage
thousands of connection, that you need to use enough RAM for TCP. If you set up a load balancer, a virtual machine that is a load balancer,
just don't think about how much Apache's RAM or NGINX RAM or HAProxy's RAM is going to consume. But think and check how many concurrent connection you are going to manage. Okay, because every connection is going to use memory.
Now in the latest Linux version, they have reduced a bit the footprint. But if you're interested in, there is some kernel mechanism that is named
TCP floating prevention. Have a look at it, it's interesting. Okay, because some years ago, they thought that it could be removed. But after some stress testing,
somebody said, okay, even if we have removed, lowered the TCP footprint on our Linux servers, still we have benefit in having a seen-flood prevention. Packets floating, okay, hey?
No, there is no seen flag there. Only a knowledge.
So if someone tried to send a packet to the server, but for example, wrong the port number or the server died, what's happened?
The first packet is sent to the router. The router can know the IP, the destination IP, and give the packet to the server.
Then the server receive the packet, but no one services are in listed. Listening on that port, and in this case, the server generate reset the packet back to the client.
And the client, this is the case of connection refused. Right? Okay. Roberto?
Okay, try to implement this case. So a client sends a packet to the server on port 80, but the server has no web server listening, so he doesn't know what to do with that packet.
This case also happened when, for example, firewall closed the incoming request to the some port.
Now the server replies, flagging the reset flag. No, not that way. The wrong part. Yeah. The server will not always discard the packet,
but wow, you can see an RST flag, and replies back.
When server replies with a reset packet, you still have information. The information you got is that the server exists.
Okay? And it is very useful to send packets to non-listening ports if you want to discover a network topology. Okay, so you don't know which IP addresses are there around, so you start trying to connect different port
and wait for reset packets to come back. Then you know those hosts are alive, and maybe if there is no port, no 80 ports, there is some other ports that is listening.
No, well, ping is something different. When you ping a host, you may have that host that don't accept, or don't reply to ping requests.
But if you have a system that lives on a host that doesn't allow ping requests, okay, so it's firewall in some way, that host might still reply to connection attempt
on different hosts, on different ports, okay? So maybe you have a firewall that disables ping requests and responses, but they don't just block all ports around. So if your network is firewall for ping, you can try to probe to other ports
and discover networking topologies. This is what trace root, that is another client program, does. It does it with UDP and with TCP. Usually with TCP, it's more probable
that you get insights of a network, because with UDP, maybe you have still firewalling. It's not easy to have TCP firewalling on all ports, because there are machine listening. So maybe some system for guests to firewall everything.
Because it's the part that is not listening. Everybody recites, okay? Remember that all these recites, when a client receive a reset with a source port,
what happens, it drops the connection, okay? So if I am exchanging communication with a server on port 80, and they receive a reset, sourcing port 80, I drop all the rest of the data.
So. Yes, yeah, but the server exists. So it's the server that responds to the client. I can even forge packets and send them to clients
with my 80 ports so that all clients just start dropping packets from a legitimate server. This is how using a random synchronization number helps, because a client accepts a reset packet
only if the synchronization and a knowledge plug match the one of the stream they are communicating on. So if I receive a reset from a server, but the reset, but the knowledge and synchronization
flag doesn't match, I just skip this reset as a forged packet, okay? Good question. Yes. If the destination is reachable,
so when you try to talk to another server, the router receive the packet, but the router don't know where send your packet, and the router give you back an hippie packet,
not TCP IP, just the hippie with the error. Now with the error, no root to host. Okay, remember, if you're looking for those ICMP packets,
then it's about no root to host and so on. If you are on your own laptop, and your laptop, your PC, doesn't resolve this address, it's your local interface replying back
with this no root to host. So if you use TCP DAMP trying to get those kind of packets, probably the best way to track them is to TCP DAMP listening on all interfaces, not just on the outgoing interface.
So if you want to have a best insights of traffic and ICMP packets, ICMP, it's out of scope for this talk. We actually should have something about the no root to host stuff,
but we don't want it to go on the ICMP stuff. You have a lot of kind of errors, and there is a table where you should check and map each kind of errors on what could have happened on the network.
So check out the map page, if you man ICMP, probably you can just get all those information. Try to TCP DAMP stuff to get. There is a very nice book that is TCP IP illustrated
where you can get a lot of examples. There are two releases. The first one, which I prefer, is very simple, very straight, and is very useful for learning all those stuff. And there is a second release that is more verbose,
and it is used, that is better than a Windows client. I don't like it very much, but it is very comprehensive, and it can be very useful if you have many protocols to check as a reference.
So let's move on with the... So and more complicated scenario with now we have all the router linked together, and now the subnet can talk,
one to each other, and the goal of this scenario is that our client in a subnet have to establish a connection to a telnet server in another subnet.
So you can speak about two clues, subnet group.
So let's connect the routers.
So you are the routers. Now you should populate this one. We spoke with him. Yeah, you should exchange with the next stop.
You can write off his name, maybe. So your L2 layer is the name of the other router, the Christian name of the other router, okay? So the router from your network.
Okay, maybe here we can have a three-way routing stuff. So one connected with two, and two connected with three. So it would be, yeah, dispatching for two routes.
And shake, okay, and shake. Start and shake now. So start and shake with the server on a different network, a different subnet. Okay, it's both two and three write to the server.
For example, on a different network.
I mean that they speak on a different network.
Not always the same layer, but they speak, for example, on a private routing network. Yeah, so it happens at the IP level. TCP is only between client and server. Router just see IP, unless they do something like
mapping and manipulating layers. There is always a C, not C-NUC.
Okay, that's going here. It's always the same, the server is always the dot one.
So, yeah.
Okay, this routing can happen on the same networks, okay? Or there can be a separate network where you route packets that is not the one which the clients are connected on. For example, there can be a 10, a 198 network.
So you and him speak on 198. And he has a routing table where the 10 dot one goes through your address on that network and you know where to deliver. And so there can be a routing network
where all the routers speak between themselves on those 108, okay? Or, well, there can be multiple hops. Boom.
Okay, if the connection is low, okay? You can start to understand how important it is to start problem network.
And if the connection is low, try to send packets to other hosts and try to get a reset to check if the problem is the server or the routing. If the packet from, if the reset packet comes back,
then probably there is a firewall on that host. Otherwise, that host would have replied with a reset or with a knowledge, okay? Try to understand. Try to mangle to track your human network.
Next year, we'll do it with 100 people and check what happens. Yeah, with the L2 game, people just start not complying
with the protocol to win the game. We made a competition for the team that was going to exchange the packet faster and they start to get just like, this is Frank, this is John, and they just go straight on.
Yeah, exactly. And then we examined all the kind of hacks they do to win and try to make similarities with the difference between hubs, router, and so on. So we found that somebody just dropped the hubs
to be smart and remember that ports are one-to-one, other reuse packets. And we hope that after this experiment this year, we can fine-tune the game to have something like that.
Next year, we wanted to do just like, Nagel algorithm and caching, buffering, and so on. But the problem is we need some refinement and if people get the first impact with TCP, it's very hard to introduce
further concepts on this kind of game. Yeah, I don't know if we have this case. We had a case with no root two hosts on that part.
Yeah, it triggered the retransmission. Okay. Yeah.
Well, probably if somebody wants to try this next year, we could plan for two sessions, two different sessions, one with TCP basic and the other one with TCP complex
but with the same teams. We can do this with exchanging people between teams. It would be very complex, I think. So now I'll leave your connection open. It's time to close it. And this is the rule
to close an established connection. It's made by four packets. The first is Fin, the flag Fin. The server responds with the hack. And then another Fin and hack,
because the connection we had is a bit directional. So we have to do two closing, one from client to server and another one from server to client.
It's possible to collapse the second and third messages in just one with both flag hack and Fin. So this modality, you can close the connection
with the three packet exchange, exchanging three packets. I want to show you the client state and server state also, starting from established connection and passing from close weight and time weight
and then close, because after closing, the client could be receive
another data messages under the closing connection. So maintain the weighting for a time, this delayed messages.
And sometimes on server, we have a lot of connection in a close weight state. This is happen when the closing,
when the closing connection are not completed. So if you want to try to close your connection, you just send Fin, receive hack.
Yes, essentially Fin means I'm not going.
to send you any more packets Fin doesn't mean I'm not going to read more packet Okay so To send the fin just means I can receive more packets from you
Okay But I won't send any more This is the reason why we need two packets A fin that is I'm not going to send any more And then A knowledge that the other one
Is done with sending Okay this last part the infamous time wait stuff is very important because As you can see
this team had a quite long routing layer Okay, they had two steps between clients and server and in that case packet transmission was slow
in this case this time wait enables to get Delayed packets to reach the client in this case Without that this connection this socket to be reused by another one
imagine that We reuse we don't have time wait The connection is closed I reuse the socket so reuse the coupling of source the destination part This destination part received our delayed packet
And what does it do with the packet that he doesn't know what to do He sends back a result He says you are not a connection established to me So you should close so a new client sends a legitimate
Connection request for example and gets back a result. He thinks that the server is not responsive instead It should be Or differently so this is important to have a time weight Okay Time weight could be problematic because means that there is a socket in use on the server
And if you have a server with both a proxying layer Okay between another process that is local Okay So for example, I have an HA proxy on the same server then the bucket service
When connection starts to get closed I have a local connection in time weight Okay or if I have firewalls or
a load balancer so you can there are mechanism for socket reuse when You think that you can have a lower time on Time weight. Okay, you should do it only if
You trust that your network has a low latency So you won't get packets very fast very with with a big delay Okay, so if you trust your network is very fast so you don't have latency
You can reuse sockets for example locally and so on Otherwise if you have time weight just uh stick with it Don't just make or use magic in into your tcp configuration because it's it probably getting things were
Words then you you get it always test stress test your tcp environment Before tuning don't tune tcp on theoretical stuff Because it's not going to work at a certain point Just do if you prove it that it's better for you
Okay. Thank you, roberto And thank you to have you for attention And so fin I would thank you very much. Danilo because at first in
This talk should have been brought to you by another colleague that had an issue and bravely danilo
Took it over Made it up Without starting it first and tried to make it to make it in a very brief time to Have it delivered to you. So thank you danilo and hope to see you next year
At europython, thanks to you polly