n-way-handshake는 왜 알아야 할까? / 기술적 겸손함

n-way-handshake는 왜 알아야 할까?

오늘은 왜 tcp 혹은 n-way-handshake에 대해서 공부해야 할까? 라는 의문점이 생겨서 여러 자료들을 취합해 보며 나름대로 공부하고 정리하게 되었다.

 

handshake란 connection을 만들기 위한 절차를 말한다. 사실 여기서 connection이란 말부터 모호하다. 그냥 연결이라고 하자기에는 감이 잘 오지 않는다.

 

TCP에 대해 정의한 RFC 793에 따르는 Connection의 정의는 다음과 같다.

 

 

Connections:

  The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection. Each connection is uniquely specified by a pair of sockets identifying its two sides.

  위에서 언급한 realibility와 flow control 매커니즘은 각 데이터 스트림에 대한 특정 상태 정보를 초기화하고 유지해야 합니다. 소켓과 sequence numbers, windows sizes를 포함하는 정보들의 집합을 connection이라고 부릅니다. 

  When two processes wish to communicate, their TCP's must first establish a connection (initialize the status information on each side). When their communication is complete, the connection is terminated or closed to free the resources for other uses.

 각각의 연결은 양쪽의 소켓에 의해 고유하게 식별됩니다. 두 프로세스가 통신하려면, TCP는 우선 양쪽의 상태를 초기화해 connection을 만들어야 합니다. 통신이 종료되면, connection은 끝나거나 종료되어 리소스를 반환해야 합니다.

  Since connections must be established between unreliable hosts and over the unreliable internet communication system, a handshake mechanism with clock-based sequence numbers is used to avoid erroneous initialization of connections.

  connections는 신뢰할 수 없는 hosts 혹은 인터넷 통신 시스템 사이에서 만들어져야 하기 때문에, clock-based sequence numbers를 사용하는 handshake 매커니즘으로 잘못된 연결 초기화를 방지합니다.  

 

즉, connection은 양쪽 소켓에 통신하려는 주체(client와 server)의 정보를 가지고 있는 상태라고 할 수 있다. 서로의 정보를 알고 있으며 심지어는 어떤 데이터를 보냈는지 또한 알고 있기 때문에 중간에 데이터를 유실하더라도 다시 데이터를 요청할 수 있게 되는 것이다.

 

handshake란 그러한 connection을 만들 때 양쪽 소켓의 정보를 교환하는 행위라고 볼 수 있다.

 

그렇다면 handshake가 어떠한 일을 하는지 알았으면 이걸 왜 알아야 하는걸까? 개인적인 견해로는 1. 문제 진단 2. 보안 3. 성능 최적화 때문이라고 생각한다.

 

 

1. 문제 진단 : 좋은 예시로 CLOSE-WAIT 혹은 TIME_WAIT 상태가 있을 것이다. 서버에 부하가 많이 발생하게 되면 이 두 상태가 발생할 수 있고, 커넥션이 고갈되어 커넥션 타임아웃의 원인이될 수 있다.

따라서 이 상황을 해결하기 위해서는 tcp 전체 흐름에 대하여 이해할 필요가 있다. 위 경우 카카오의 트러블 슈팅 글에 매우 잘 나와있으니 한 번씩 읽어보면 좋다.

• https://tech.kakao.com/2016/04/21/closewait-timewait/

2. 보안 : 예시로 SYN Flood 공격이 있을 것이다. SYN Flood 공격이 발생하면 SYN Cookie라는 걸 만들게 되고 이는 자원 고갈에 영향을 주게 된다. 따라서 이를 알고 방지하려면 역시 handshake에 대해 알아야 한다.
3. 성능 : n-way-handshake에서 성능 문제가 대두되는 이유는 결국 매 요청마다 데이터 교환과 더불어 n번의 패킷 교환이 추가적으로 수행되어야 한다는 점이다. 패킷을 주고받는 과정을 Round Trip이라고 부르며, 왕복 시간은 RTT라고 불린다. 이는 네트워크 레이턴시에 영향을 주므로 매우 중요한 개념이다.

한 번의 데이터를 교환하기 위하여 이러한 부가적인 round trip을 수행하는 것은 배보다 배꼽이 더 큰 행위가 될 가능성이 높다. 따라서 이러한 round trip을 줄이기 위해서 여러 노력들이 있어왔다.

 

좋은 예로 keep-alive가 있다. 이는 HTTP/1.1에서 기본 옵션이 된 것으로 유명한데, 쉽게 말하자면 TCP 요청이 끝난 후 매번 close하지 않고 재사용할 수 있도록 만드는 것이다. 이렇게 요청이 처리된 후에도 connection을 유지하는 경우를 persistent connection이라고 표현한다.

 

keep-alive에서도 timeout이나 max(connection 유지하는 request 수)를 조정할 수도 있다.

• 이 내용은 이 글에서 잘 다루고 있다 : https://etloveguitar.tistory.com/137

이 외에도 connection pooling을 활용해 handshake를 생략하는 효과를 낸다던가, (handshake와는 관련 없지만) rtt를 줄이기 위해 http multiplexing(HTTP/2)을 도입한다던가, tfo를 도입해 SYN에 data를 밀어 넣어 round trip 수를 줄인다던가, false start 혹은 0-RTT(TLS 1.3)를 적용해 등 round trip 수를 줄이는 등 많은 시도들이 있어왔다.

 

결론
n-way-handshake 등 tcp에 대한 세부적인 내용을 이해하면 진단, 보안, 최적화 등에 대해서 고려할 수 있는 요소들이 많아지기 때문에 공부해야 한다.

 

참조

• https://datatracker.ietf.org/doc/html/rfc793
• https://www.theregister.com/2011/05/19/google_ssl_breakthrough/
• https://m.blog.naver.com/cr0sscert/221706613801

일기

기술적 겸손함

예전에 영한님이셨나? 어떤 분에게 어떤 사람이 성장하기 좋은 개발자라고 생각하시는지 여쭤봤을 때 기술적 겸손함을 가진 개발자를 말씀하셨다. 그때는 단순히 아 그렇구나 하는 생각이었는데 오늘 그게 크게 와닿은 일이 있었다.

 

나는 K-Devcon이라는 커뮤니티에서 종종 활동하곤 하는데, 그곳의 구루 중 한 분인 성욱님이 계시다. 그 분께서 oom_killer 관련한 이야기를 하시는데, 최근 강진우님 강의에서 나왔던 내용과 비슷해 그 부분은 고려하지 않으시는지 궁금해서 질문을 드렸다.

 

 

그리고 이 대화를 하시고 나서 그 날 바로 이런 글을 올리셨다.

• https://sungwookkang.com/1540

이걸 보고 세 가지 크게 놀란 점이 있었다.

1. 고레벨 개발자라고 해서 모든 걸 아는 건 아니다.
2. 모르는 게 있더라도 자기보다 한참 낮은 레벨의 사람이더라도 물어본 것
3. 모르는 게 있으면 그 날 바로 조사하고 공부하는 것

1은 어찌 보면 당연할 수도 있는 것이고 3은 존경스러울 것 까지는 아니였는데 2에서 큰 감명을 받았고, 전에 어떤 멘토님께서 말씀하신 기술적 겸손함이라는 단어가 떠올랐다.

 

성욱님은 정말 오랜 기간 IT 업계에서 일을 하셨고, 나는 아직 신입도 채 안된 병아리 개발자다. 둘 사이에는 엄청난 레벨의 차이가 존재하고, 그럼에도 불구하고 질문할 수 있다는 것은 쉽지 않은 일이라고 생각한다.

 

당장 나만 해도 신입생들이 내가 모르는 것에 대해 말할 때 내가 모름을 인정하고 질문할 수 있을까? 하는 생각이 들었고, 다른 한 편으로는 본인에 대해 자신감과 높은 자존감이 있기 때문에 자신의 약함을 드러낼 수 있는 것 아닐까? 하는 생각도 들었다.

 

아니 애초에 다른 사람에게 질문하는 행위 자체가 약점을 드러내는 행위가 아니고 협업하는 행위가 아닐까 하는 생각이 들었다.

 

그 멘토분께서 말씀하신 기술적 겸손함이란 바로 이런 것 아닐까 하는 생각이 든다. 자신의 현재 상태를 인정하고 약한 부분이 있으면 도움을 요청할 수 있는 것. 다른 사람들의 의견에 귀 기울이게 되므로 오픈 마인드가 될 수 있는 것. 메타 인지를 높여 현재 역량을 인지하고 부족한 부분을 채워나갈 수 있는 것.

 

Soft Skill을 기르기 위해 내가 지향해야 할 바는 바로 이것이 아닐까 생각이 든다.