larrylv (larrylv)

Write a TCP stack in Ruby

larrylv — Fri, 27 Nov 2015 10:31:53 +0800

Blog post: http://blog.larrylv.com/write-a-tcp-stack-in-ruby/

I read [Julia][julia-twitter]'s article [What happens if you write a TCP stack in Python?][julia-article] last year, and since then I really wanted to implement a TCP stack in Ruby language. I saved Julia's article in my [Pocket][pocket], then moved it to my browser bookmark folder, but never touched it again.

This week, I decided to give it a try and it turns out to be really fun. In this post, I'm going to follow Julia's steps and blog some implementation details.

My codes are here: [larrylv/teeceepee][my-teeceepee], the name teeceepee is borrowed from Julia's repo: [jvns/teeceepee][julia-teeceepee].

What we would like to do here is, I quote from Julia's blog:

open a raw network socket that lets me send TCP packets
send a HTTP request to GET google.com
get and parse a response
celebrate!

I use a gem called [PacketFu][packetfu] to read and write packets. I don't think I could write the stack in such a short time without it, it's really awesome.

Step 1: the TCP handshake

The TCP three-way handshake is:

me: SYN
google: SYNACK
me: ACK

Pseduo codes could be something like this:

send_syn_packet
read_response
send_ack_packet

With PacketFu, sending a packet is pretty simple:

require 'packetfu'

config = PacketFu::Utils.whoami?

synpkt = PacketFu::TCPPacket.new(config: config, flavor: "Linux")
synpkt.ip_daddr      = "216.58.221.142" # ip of google.com
synpkt.tcp_dst       = 80               # port of google.com
synpkt.tcp_flags.syn = 1                # SYN
synpkt.recalc

synpkt.to_w

For ack packet, just set pkt.tcp_flags.ack = 1.

As to read response, we need to filter packets from the interface.

require 'packetfu'

cap = PacketFu::Capture.new(
  iface: config[:iface],
  start: true,
  filter: "tcp and src 216.58.221.142"
)

cap.stream.each do |pkt|
  # parse pkt and decide what to do next
  puts pkt
end

The filter parameter for PacketFu::Capture is very interesting, it's a bpf filter and you could find the syntax documentation [here][bpf-syntax]. tcp and src 216.58.221.142 means we would like to filter tcp packets from ip 216.58.221.142, which are exactly what we want to parse.

tcpdump also uses bpf filter to filter packets you want.

Let's say we just want the SYNACK packets. With tcpdump:

$ sudo tcpdump -i eth0 'tcp[13]=18'

What does tcp[13]=18 mean? Here is the TCP Header Format:

We could see that the last six bits of fourteenth byte stand for tcp flags, and the previous two bits are both 0. So for SYNACK packets, tcp flags would be: 010010, the value would be 16 + 2 = 18.

Bpf is super powerful, and if you would like to know more examples, check tcpdump manpage.

In this step, I'm gonna ignore the part of how SEQ and ACK number work, you could check this [article][ack-number-article] to learn more.

Step 2: Kernel sends a RST after receiving the SYNACK packet

Julia described this in her article, instead of what we think of how it would work, it didn't.

As the picture shown, after receiving SYNACK packet from google.com, a RST packet was sent (obviously not by us).

I will just quote Julia's explaining here:

my Python/Ruby program: SYN
google: SYNACK
my kernel: lol wtf I never asked for this! RST!
my Python/Ruby program: ... :(

Julia used ARP spoofing to pretend a different IP address, and someone commented about using tap/tun interfaces instead. I tried the two ways both, but none of them worked for me (maybe my implementations are not good). I struggled to find a way to get my kernel just ignore the packet for, like the whole afternoon. Finally, when I used my nameserver's ip as src_ip in the packet, it worked! I'm not exactly sure how this works, but it fixed my problem. I will leave this as a question and ask some network folks later.

Now, the three-way handshake works!

Step 3: get a web page!

This is pretty easy, what we should do is:

send a packet containing a HTTP GET request
listen for packets in response
parse the packet
decide what to do based on tcp flag

Implementing the last one will cost you some time probably, since it comes down to some parts of [TCP Finite State Machine][tcp-fsm].

Constructing a HTTP Get request is quite easy, just include GET some_path HTTP/1.0\r\nHost: hostname\r\n\r\n in your PSH packet.

I use a seperate thread to listen for packets from the destination IP, and after parsing the packet, it will send it to main thread and let it respond based on its state and packet tcp flags.

class Listener
  def initialize(conn, config, dst_ip)
    @conn = conn
    @cap = PacketFu::Capture.new(
      iface: config[:iface],
      start: true,
      filter: "tcp and dst #{config[:ip_saddr]} and src #{dst_ip}"
    )
  end

  def listen
    @cap.stream.each do |pkt|
      state = @conn.handle(PacketFu::Packet.parse pkt)
      return if state == Teeceepee::CLOSED_STATE
    end
  end
end

More codes on [GitHub][my-teeceepee], this [tcp.rb][my-teeceepee-tcp-rb] file particularly, advice welcome!

Sum Up

I'm really glad that I finally give this a try and get it worked. Couldn't say more thanks to Julia for her article and codes, I really learned a lot from them.

The last time I wrote packets related codes is about 5 or 6 years ago during collegue's networking lesson. Mostly with C language back then. Thanks to PacketFu gem, I really don't need to some dirty work.

Anyway, this is much more fun than I expected. The moment it worked I was really beyond happy. Try it with your preferred language, have some fun with me too!

[julia-twitter]: https://twitter.com/b0rk [julia-article]: http://jvns.ca/blog/2014/08/12/what-happens-if-you-write-a-tcp-stack-in-python/ [pocket]: https://getpocket.com [my-teeceepee]: https://github.com/larrylv/teeceepee [my-teeceepee-tcp-rb]: https://github.com/larrylv/teeceepee/blob/master/tcp.rb [julia-teeceepee]: https://github.com/jvns/teeceepee/ [packetfu]: https://github.com/packetfu/packetfu [bpf-syntax]: http://biot.com/capstats/bpf.html [ack-number-article]: http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/ [tcp-fsm]: http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm

Global Variables in Rails

larrylv — Fri, 26 Dec 2014 14:59:10 +0800

Blog: http://blog.larrylv.com/global-variables-in-rails/

In a Rails application, sometimes you may wanna use global variables for every request, with which you don't have to send the object as a parameter everywhere, like current_user for model layers (which may not be a good idea).

So how could we do that?

Ruby Global Variables

If you know Ruby well, you may know variable with a beginning with $ is global.

But global variables with $ prefix are supposed to be accessible from every single palce of your code, so they are shared among all threads, and that's definitely not what we want, right?

So basically, don't use Ruby native global variables, ever.

Thread.current

So we want our global variables to be thread-safe, a.k.a thread-local.

This is where Thread comes in.

Threads are the Ruby implementation for a concurrent programming model.

Programs that require multiple threads of execution are a perfect candidate for Ruby's Thread class.

With Thread.current method, you could get the currently executing thread. Then you could use Thread.[] and Thread.[]= to get and set thread-local variables, respectively.

Thread.current[:current_user] = user

If you read the links of ruby-doc carefully, you may notice that actually the variable is fiber-local instead of thread-local. Since we rarely use fibers these days, especially for new 2.x Ruby versions, we could assume this is equal to thread-local. But if you do use fibers, and want your variables to be thread-local, please use Thread.thread_variable_set and Thread.thread_variable_get.

But there is one problem.

If you use Thread.current with fancy evented/threaded web servers like Thin or Puma, please watch out! Values can stick around longer that you'd expect, and this can cause bugs. For example, if we had this in our controller:

def index
  Thread.current[:counter] ||= 0
  Thread.current[:counter] += 1

  render :text => Thread.current[:counter]
end

If we ran this on MRI with Webrick, you'd get 1 as output, every time. But if you run it with Thin or Puma, you get 1, then 2, then 3...

So what's the solution?

Steve Klabnik releases a gem called request_store to do that for you. Everywhere you used Thread.current, just change it to RequestStore.store. And no matter what server you use, you'll get 1 every time: the storage is local to that request.

def index
  RequestStore.store[:counter] ||= 0
  RequestStore.store[:counter] += 1

  render :text => RequestStore.store[:counter]
end

Codes of the gem are pretty simple, just insert a middleware to Rails and use Thread.current[:request_store] to store variables, and clear Thread.current[:request_store] after every request.

But with Thread.current(or RequestStore.store), there are two pains may bother you later:

1. Someone could accidentally overwrite your data.

If the other developer picks the same key with yours, and overwrite it somewhere, you app will just break. Or if you are a gem author, that is really something you need to consider.

2. It's not well-structured.

Or we could say that it's not very OO. You don't know what's in your Thread.current[], and you're gonna have to read every line of codes with Thread.current[].

And with these two pains, we may ask: What's the better solution?

ActiveSupport::PerThreadRegistry

ActiveSupport::PerThreadRegistry module is used to encapsulate access to thread local variables.

Instead of polluting the thread locals namespace:

Thread.current[:connection_handler]

We could define a class that extends this module:

module ActiveRecord
  class RuntimeRegistry
    extend ActiveSupport::PerThreadRegistry
    attr_accessor :connection_handler
  end
end

and invoke the declared instancec accessors as class methods. So

ActiveRecord::RuntimeRegistry.connection_handler = connection_handler

sets a connection handler local to the current thread, and

ActiveRecord::RuntimeRegistry.connection_handler

returns a connection handler local to the current thread.

This feature is accomplished by instantiating the class and storing the instance as a thread local keyed by the class name. In the example above a key "ActiveRecord::RuntimeRegistry" is stored in Thread.current.

The implementation is pretty simple, too. See the codes here: module PerThreadRegistry.

With PerThreadRegistry module, the previous pains concerning you are gone.

As to the previous RequestStore problem, someone provides a solution, or you could just hack it yourself. It's quite simple.

Wrap It Up

Don't ever use Ruby native global variables.
Thread.current could do it, but it's not good for complicated apps or codes of a gem.
Clear thread local variables after every request, or it may stick around longer than you'd expect.
Use ActiveSupport::PerThreadRegistry for better global variables management and document.

References

How Did Tenderlove and Others Speed Up Rails?

larrylv — Wed, 08 Oct 2014 16:19:48 +0800

Blog Link: http://blog.larrylv.com/how-did-tenderlove-and-others-speed-up-rails/

Rails 4.2.0 beta1 was released August 20, 2014. And according to dhh's release post, and I quote,

a lot of common queries are now no less than twice as fast in Rails 4.2!

So, what did Rails team -- or more specifically -- tenderlove (Aaron Patterson) do to improve Rails/ActiveRecord so much? Let's find out through some commits.

Performance Tools

Here are some tools Aaron has used for measuring performance according to his Cascadia Ruby 2014 talk:

You should definitely checkout these tools. It would be very useful in your daily Ruby/Rails development.

GitHub Commit: drastically reduce object allocations

Inside the tag_option method, the value variable was html escaped first, then interpolated into a string.

def tag_option(key, value, escape)
    value = value.join(" ") if value.is_a?(Array)
    value = ERB::Util.h(value) if escape # html escaped here
    %(#{key}="#{value}")                 # interpolated into a string here.
end

And if digging into html_escape (alias as h) method, we will see that there will be a AS::SafeBuffer object allocated:

def html_escape(s)
    s = s.to_s
    if s.html_safe?
        s
    else
        s.gsub(HTML_ESCAPE_REGEXP, HTML_ESCAPE).html_safe # a String allocated first(by String#gsub),
                                                           # then a SafeBuffer object allocated.
    end
end

So for tag_option, there will always be an AS::SafeBuffer useless object allocated. This could be solved by adding another escape method but doesn't wrap string with an AS::SafeBuffer. And tag_option should call that method instead of the old one.

And this tiny change reduced the AS::SafeBuffer objects from 1527 per request to about 500 per request according to Aaron's benchmark. It is trully drastically, awesome!

GitHub Commit: No need for another hash allocation / merge!

This commit is very simple, but it should really attrack our attention when writing Ruby codes.

Hash#merge! will allocate a new hash, but with Hash#[] this would not happen. And accoriding to my benchmark(I wrote a blog about Performance Differences in Ruby, you may would like to check it out) , it really matters.

def slow
  (1..10).inject({}) { |h, e| h.merge!(e => e) }
end

def fast
  (1..10).inject({}) { |h, e| h[e] = e; h }
end

slow    72613.7 (±9.9%) i/s -     364662 in   5.082934s
fast   158245.6 (±7.1%) i/s -     796005 in   5.056857s

There are a large number of commits like this in Rails repo recently (because performance really matters, right?).

Fewer hash allocations when calling url_for by Aaron.
This commit by @sferik, changing Hash#keys.each to Hash#each_key. Because Hash#keys.each will allocate an array of keys, but Hash#each_key iterates through the keys without allocating a new array. I also benchmark on this in my article I mentioned above.
And this commit by Aaron is also the same, use Hash#each_key to avoid some objects allocation.
Or this one.

@sferik gave a talk about these skills at Baruco 2014, and he is also who made me want to blog and benchmark these in my article. The video has not been released, but you should definitely check out his slides Writing Fast Ruby.

GitHub Commit: reduce object allocations

This commit is basically same with the previous one. It's about performance differences on how to use Hash#zip. And Aaron's commit message explains it all.

x = [1,2,3,4]
y = [3,2,1]

def test x, y
  hash = {}
  x.zip(y) { |k,v| hash[k] = v }
  hash
end

def test2 x, y
  Hash[x.zip(y)]
end

def test3 x, y
  x.zip(y).each_with_object({}) { |(k,v),hash| hash[k] = v }
end

def stat num
  start = GC.stat(:total_allocated_object)
  num.times { yield }
  total_obj_count = GC.stat(:total_allocated_object) - start
  puts "#{total_obj_count / num} allocations per call"
end

stat(100) { test(x,y) }
stat(100) { test2(x,y) }
stat(100) { test3(x,y) }

__END__
2 allocations per call
7 allocations per call
8 allocations per call

Sum Up

When somenone outsite of Ruby/Rails community talks bout Rails, the performance will always be brought to the conversation. And it really concerns developers when choosing tools to build their apps. After giving so much attention to impove it, we could say Rails is getting faster and Rails will be much more faster later.

So thanks to everyone who has contributed to Rails performance improvement, you guys make this community better and better.

Performance Differences in Ruby

larrylv — Mon, 12 May 2014 23:30:36 +0800

http://blog.larrylv.com/performance-differences-in-ruby/

http://parley.rubyrogues.com/t/dramatic-performance-differences-in-ruby/2151

前几天 @sferik 在 Parley 上说最近在准备一个关于 Performance in Ruby 的 talk，发贴讨论了 Ruby 中哪些写法会造成性能的巨大提升，我顺手整理了下帖子内容并实验了一下。

Benchmark 环境：MacBook Air Mid 2012, Ruby 2.1.1, gem benchmark-ips.

Proc#call versus yield

require 'benchmark/ips'

def slow(&block)
  block.call
end

def fast
  yield
end

Benchmark.ips do |x|
  x.report("slow") { slow { 1 + 1 } }
  x.report("fast") { fast { 1 + 1 } }
end

slow   770263.8 (±4.8%) i/s -    3849832 in   5.010201s (5 秒钟可运行 3849832 次)
fast  3985294.7 (±8.7%) i/s -   19751563 in   5.001024s (5 秒钟可运行 19751563 次)

从上面的 benchmark 结果中可以看出两种写法的显著性能差异，这主要是因为第一种写法中要不断的创建 Proc 对象赋给 block 参数导致的。

Enumerable#map and Array#flatten versus Enumerable#flat_map

def slow
  (1..50).map{ |i| i.divmod(7) }.flatten
end

def fast
  (1..50).flat_map{ |i| i.divmod(7) }
end

slow   32514.2 (±6.8%) i/s -     162134 in   5.014068s
fast    57858.6 (±7.3%) i/s -     292463 in   5.084633s

Hash#merge versus Hash#merge! (bang methods, in general)

def slow
  (1..10).inject({}) { |h, e| h.merge(e => e) }
end

def fast
  (1..10).inject({}) { |h, e| h.merge!(e => e) }
end

slow    22054.4 (±6.3%) i/s -     110081 in   5.012558s
fast     75393.0 (±9.3%) i/s -     375577 in   5.028409s

Hash#merge! versus Hash#[]=

def slow
  (1..10).inject({}) { |h, e| h.merge!(e => e) }
end

def fast
  (1..10).inject({}) { |h, e| h[e] = e; h }
end

slow    72613.7 (±9.9%) i/s -     364662 in   5.082934s
fast   158245.6 (±7.1%) i/s -     796005 in   5.056857s

Hash#fetch with second argument versus Hash#fetch with block

def slow
  {:foo => :bar}.fetch(:foo, (1..10).to_a)
end

def fast
  {:foo => :bar}.fetch(:foo) { (1..10).to_a }
end

slow   412806.8 (±11.2%) i/s -    2037520 in   5.009145s
fast  1134439.1  (±8.1%) i/s -    5662160 in   5.027080s

String#gsub versus String#sub

def slow
  'http://parley.rubyrogues.com/'.gsub(%r{\Ahttp://}, 'https://')
end

def fast
  'http://parley.rubyrogues.com/'.sub(%r{\Ahttp://}, 'https://')
end

slow   237660.4 (±5.0%) i/s -    1190664 in   5.023559s
fast   320335.6 (±5.1%) i/s -    1614839 in   5.055553s

String#gsub versus String#tr

def slow
  'slug from title'.gsub(' ', '_')
end

def fast
  'slug from title'.tr(' ', '_')
end

slow   187349.7 (±6.8%) i/s -     933140 in   5.012634s
fast  1216071.5 (±8.9%) i/s -    6050762 in   5.024810s

Parallel versus sequential assignment

def slow
  a, b = 1, 2
end

def fast
  a = 1
  b = 2
end

slow   189642.1 (±7.6%) i/s -     947520 in   5.031411s
fast  1180907.4 (±7.1%) i/s -    5872020 in   5.002410s

Explicit versus implicit String concatenation

def slow
  "foo" + "bar"
end

def fast
  "foo" "bar"
end

slow  1998832.8 (±5.5%) i/s -    9974259 in   5.005887s
fast  3559754.8 (±6.8%) i/s -   17747928 in   5.012536s

Using exceptions for control flow

def slow
  self.no_method
rescue NoMethodError
  "doh!"
end

def fast
  respond_to?(:no_method) ? self.no_method : "doh!"
end

slow   194665.7 (±10.9%) i/s -     963144 in   5.029578s
fast  2248844.0  (±6.1%) i/s -   11241017 in   5.020091s

while loops versus each_with_index

ARRAY = [1, 2, 3, 1, '2', 4, '5', 6, 7, 8, 9,'10']

def slow
  hash = {}

  ARRAY.each_with_index do |item, index|
    hash[index] = item
  end

  hash
end

def fast
  hash = {}
  index = 0
  length = ARRAY.length

  while index < length
    hash[index] = ARRAY[index]
    index += 1
  end

  hash
end

slow   147515.1 (±9.6%) i/s -     734100 in   5.038291s
fast   183634.1 (±6.5%) i/s -     918335 in   5.023060s

Related Pull Request for ActiveRecord: Perf: micro optimised Result column hash_row creation