201–210 of 236 posts
Earlier quoted context omitted.
FYI both a TCP SYN and SYN/ACK can carry a payload (which could be the GET and RESPONSE)
Yeah but in practice no browser does this. There is no system call on Linux or Windows to push data as part of the SYN packet. You would have to craft TCP/IP packets and their headers with a raw socket...
I am half serious, but how about making HTML served in TXT records a standard trick for serving small web pages very quickly? There are way fewer network round trips: 1. DNS query for TXT record for example.com 2. DNS reply with HTML content Compared with the traditional 7 steps: 1. DNS query for A record for example.com 2. DNS reply with x.x.x.x 3. TCP SYN to port 80 4. TCP SYN/ACK 5. TCP ACK 6. HTTP GET 7. HTTP rep…
I already did this many years ago. It works well.
I also do not use DNSSEC (unencrypted DNS packets) opting instead for dnscurve (encrypted DNS packets).
What is still missing from the DNS world is a server that can handle pipelined (TCP) DNS queries (multiple lookups in the same request). I think the spec allows for it but no one ever implemented it as far as I know.
In your thought experiment, that would be "HTTP/1.1 pipelining".
I use HTTP pipelining everyday via command line utlities and where "web browsing" is concerned I find it hard to live without.
http://mxtoolbox.com/SuperTool.aspx?action=txt:jamiehankins....
In playing around with this hack, I discovered that Dreamhost doesn't properly escape TXT records in their admin interface when modifying DNS records. I put an iframe in and it shows the box but the src is removed; it also killed the page at that point so I'm unable to remove it...
Add the domain to your hosts file to make it not resolve, that should fix it.
So uh. This works on a few websites. A couple I've found http://dig.whois.com.au/dig.php?dom=jamiehankins.co.uk&type=... http://mxtoolbox.com/SuperTool.aspx?action=txt:jamiehankins....
Earlier quoted context omitted.
802.1x covers access control to networks. MAC addresses are not for access control. Not that a court would agree with my logic, of course.
Yeah, you might have a tough time explaining to the judge that Media Access Control addresses are not for access control.
Earlier quoted context omitted.
ASN.1/BER is a pain in the ass. I'd rather gzip json. Or poke chopsticks in my eyes. (creds: http://tools.ietf.org/html/rfc1697 )
^ What that guy said. ASN.1 parsers are super complicated and have been the cause of remote exploits more than once.
Earlier quoted context omitted.
FYI both a TCP SYN and SYN/ACK can carry a payload (which could be the GET and RESPONSE)
Yeah but in practice no browser does this. There is no system call on Linux or Windows to push data as part of the SYN packet. You would have to craft TCP/IP packets and their headers with a raw socket...
Earlier quoted context omitted.
You are incorrect. An HTTP GET still requires a 3-way TCP handshake, so your suggestion requires 5 steps not 2: 1. TCP SYN to port 80 2. TCP SYN/ACK 3. TCP ACK 4. HTTP GET 5. HTTP reply with HTML content
FYI both a TCP SYN and SYN/ACK can carry a payload (which could be the GET and RESPONSE)
The TCP Fast Open proposal gets around this by using a cookie, so that the first connection requires a normal three-way-handshake, but subsequent connections between the same client and host can use an expedited handshake that eliminates a round trip.
Earlier quoted context omitted.
FYI both a TCP SYN and SYN/ACK can carry a payload (which could be the GET and RESPONSE)
Yeah but in practice no browser does this. There is no system call on Linux or Windows to push data as part of the SYN packet. You would have to craft TCP/IP packets and their headers with a raw socket...