DON’T ROLL YOUR
OWN HTTP SERVER
JOEL W KALL, CHIEF CCO OFFICER @ LOOP54
Loop54
• On-site e-commerce search engine
• SaaS
• Relevant search results
• Machine learning
In the beginning
• Small scale prototype
• Nothing fancy – just accept requests
• No configuration
HTTP request-response sample
POST /path HTTP/1.1
Content-Type: application/json
Content-Length: 28
{
“key”:”value”
}
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 31
{
"anotherkey":"andavalue"
}
HOLD MY BEER
HOW HARD CAN IT BE?
ENCODING
HEADACHE #1
SOCKET QUEUE
HEADACHE #2
CONTENT LENGTH
HEADACHE #3
NAGLING
HEADACHE #4
100 CONTINUE
HEADACHE #5
VERSIONING
HEADACHE #6
KEEP-ALIVE & PIPELINING
THE NAIL IN THE COFFIN
Kestrel to the resqueue
• Part of ASP.NET Core, embeddable
• Cross-platform
• 5% faster, 15% less memory
• Full HTTP support
• Probably more secure
DON’T DO IT!
BUT IF YOU DO, READ UP BEFOREHAND

Don't roll your own HTTP server

Editor's Notes

  • #2  co-founder Chief CCO Officer recursive other co-founder Mike mathematician poster boy don't roll
  • #3 about Loop54 API integrating smart on-site search ecommerce machine learning relevant synonyms contextual information automatically
  • #4 first prototype great API accept HTTP requests and respond start testing live code configuration HTTP features available servers expensive complex to set up both researching
  • #5 simple HTTP sample request headers data similar response text based simple to parse
  • #6 how hard can it be Hold my beer! might expect immediately headaches list
  • #7 1 Encoding decode the bytes TCP stream characters headers easy ASCII body Content-Type header still need to be smart UTF-16 Little endian or big endian different order Byte-order-mark sometimes it doesnt scan the text figure out ANSI code pages looked this up beforehand add that in What next
  • #8 3 queue not 3 lines of code need configuration threads busy? queue connections drop packets high loads each request new connection 3 second response time ok add queue
  • #9 2. Content-Length can't assume body single packet long body keep reading How know? Content-Length read header read data didn't have logic read once fine in testing production longer requests triggered errors add code what else
  • #10 4 Nagling heard of problem in TCP too many packets congested ack delayed re-transmits more congestion spirals out of control unusably slow overhead small packets bad TM combat this John Nagle algorithm buffers packets one big packet good but x00ms disable client server read up just a line of code or two. We're done, right?
  • #11 5 100 Continue some clients no data first request instead without data header "Expect" permission polite clients asking for permission also means add support 100 Continue stupid well-mannered computers
  • #12 6 Versioning ran through different versions hard-coded API implementations API versions properly different routes We didn't, no route support stuck with a mess clean up now
  • #13 7 Keep alive ultimate nail in the coffin realized keep alive. lost packet wait a while new connection 3 seconds, old connection smarter, match latency, faster each request new connection always slow HTTP feature keep alive client server negotiate hard to implement pool the connections match with threads explicit close timeout Maybe we should have read up on this beforehand.
  • #14 Kestrel web server Part of ASP.NET Core, embeddable Cross-platform 5% faster, 15% less memory Full HTTP support Probably more secure
  • #15 ultimate advice to anyone building a new HTTP-based API and who feels tempted to just roll your own super-simple server. Dont do it! And if you do - read up on it beforehand and I'm sure the temptation will go away.