With increasing access to interconnected IP networks, people demand a faster response time from Internet services. Traffic from web browsing, the second most popular service, is particularly time-sensitive. This demands reliability and a guarantee of delivery with a good quality of service from ISPs. Additionally, the majority of the population do not have the technical background to monitor the delay themselves from their home networks, and their ISPs do not have a vantage point to monitor and diagnose network problems from the users’ perspective. Hence, the aim for this research was to characterise the “in-protocol” network delay encountered during web browsing from within a LAN. This research presents TCP traffic monitoring performed on a client device as well as TCP traffic monitoring over both the client-end and the server-end devices separately observing an automated web client/server communication. This was followed by offline analysis of the captured traces where each TCP flow was dissected into: handshake, data transfer, and teardown phases. The aim behind such extraction was to enable characterisation of network round-trip delay as well as network physical delay, end host processing delay, web transfer delay, and packets lost as perceived by the end hosts during data transfer. The outcome of measuring from both end devices showed that monitoring from both ends of a client/server communication results to a more accurate measurement of the genuine delay encountered when packets traverse the network than when measuring from the client-end only. Primarily, this was concluded through the ability to distinguish between the pure network delay and the kernel processing delay experienced during the TCP handshake and teardown. Secondly, it was confirmed that the two RTTs identified in a TCP handshake are not symmetrical and that a TCP teardown RTT takes longer than the TCP handshake RTT within the same TCP flow since a server must take measures to avoid SYN flooding attacks. Thirdly, by monitoring from both end devices, it was possible to identify routing path asymmetries by calculating the physical one-way delay a packet using the forward path in comparison to the physical delay of a packet using the reverse path. Lastly, by monitoring from both end devices, it is possible to distinguish between a packet that was actually lost and a packet that arrived with a higher delay than its subsequent packet during data transfer. Furthermore, utilizing TCP flows to measure the RTT delay excluding end host processing gave a better characterisation of the RTT delay as opposed to using ICMP traffic. / Med ökande tillgång till den sammankopplade IP-nätet, krävs det en snabbare responstid från Internettjänster. Trafik från surfning, den näst mest populära tjänsten är särskilt tidskänsliga. Detta kräver tillförlitlighet och en garanti för data leverans med en god servicekvalitet från Internetleverantörer. Dessutom har de flesta av befolkningen inte den tekniska bakgrunden för att övervaka fördröjning sig från sina hemmanätverk, och deras Internetleverantörer har ingen utsiktspunkt för att övervaka och diagnostisera nätverksproblem från användarnas perspektiv. Därför syftet med denna forskning är att karakterisera “in-protokoll”  fördöljingen i nätet, som påträffas under surfning inifrån ett LAN. Denna forskning visar TCP-trafik monitoring som utförs på en klientenhet, samt separat TCP-trafik monitoring över både klient-end och serve-end enheter, för att observera en automatiserad webbklient / server-kommunikation. Detta följs av offline analys av de infångade tracer där varje TCP flöde dissekerades in: handskakning, dataöverföring, och nedkoppling faser. Syftet bakom sådan utvinning är att möjliggöra karakterisering av nätverk fördröjning samt nätverkets fysiska fördröjning, behandlingsfördröjning, webböverföringsfördröjning och förlorade paket som uppfattas av end-device under dataöverföring. The outcome of measuring from both end devices showed that monitoring from both ends of a client/server communication results to a more accurate measurement of the genuine delay encountered when packets traverse the network than when measuring from the client-end only. Primarily, this was concluded through the ability to distinguish between the pure network delay and the kernel processing delay experienced during the TCP handshake and teardown. Secondly, it was confirmed that the two RTTs identified in a TCP handshake are not symmetrical and that a TCP teardown RTT takes longer than the TCP handshake RTT within the same TCP flow since a server must take measures to avoid SYN flooding attacks. Thirdly, by monitoring from both end devices, it was possible to identify routing path asymmetries by calculating the physical one-way delay a packet using the forward path in comparison to the physical delay of a packet using the reverse path. Lastly, by monitoring from both end devices, it is possible to distinguish between a packet that was actually lost and a packet that arrived with a higher delay than its subsequent packet during data transfer. Furthermore, utilizing TCP flows to measure the RTT delay excluding end host processing gave a better characterisation of the RTT delay as opposed to using ICMP traffic. Resultatet av mätningarna från både slut-enheter visar att övervakning från båda ändar av en klient / server-kommunikation resulterar  en noggrannare mätning av fördröjningar som uppstår när paketen färdas över nätverket än vid mätning från den enda klienten. Främst avslutades detta genom förmågan att skilja mellan den rena nätfördröjningen och kernel bearbetning under TCP handskakning och nedkoppling. För det andra bekräftades att de två RTT som identifierats i en TCP handskakning inte är symmetriska och att TCP nedkoppling RTT är längre än TCP handskakning RTT inom samma TCP flödet, eftersom servern  måste vidta åtgärder för att undvika SYN översvämning attacker. För det tredje, genom att övervaka från båda avancerade enheter, var det möjligt att identifiera path asymmetrier genom att beräkna den fysiska envägsfördröjningen av ett paket på framåtriktade banan i jämförelse med den fysiska fördröjningen för ett paket på den omvända banan. Slutligen genom att övervaka från båda end enheter, är det möjligt att skilja mellan ett paket som faktiskt förlorades och ett paket som kom med en högre fördröjning än dess efterföljande paket under dataöverföring. Dessutom utnyttjande av TCP flöden för att mäta RTT exkluderat end-nod porocessering gav en bättre karakterisering av RTT fördröjning jämfört med att ICMP-trafik.