2016년은 여행과 함께 Start


이번에는 산업기능요원의 신분으로는 처음으로, 해외여행을 가게되었습니다. 사실 이번 여행은 제가 근무하고있는 회사에서 복지차원으로 제공해주는 휴가비를 받기 위해서 계획을 하였었던 건데요, 어쩌다보니 생각보다 산업기능요원을 일찍 하게 되어서 휴가비는 받지 못하고 "군인"의 신분으로 가게되었습니다.


처음으로 가족들이나 학교에서 단체로 떠나지 않고 저와 제 친구 둘이서 떠나는 여행인데, 안전하게 잘 다녀왔으면 좋겠습니다. 


마침 오늘이 또 회사 근속 1주년이였습니다. 1년 (하고 4개월) 동안 열심히 배우고 달려왔으니 이번 여행을 한번 쉬어가는 시간으로 잡고, 맘 편히 쉬고올 예정입니다.



왜 하필 후쿠오카?


후쿠오카 여행 계획을 제 친구와 짜기 시작한지 정말 6개월 정도가 되어서 이제는 왜 하필 후쿠오카를 여행지로 정했는지 잘 기억은 나지 않지만, 아마 제가 후쿠오카를 한번도 가본경험이 없어서였던 것 같네요. 오사카나 도쿄는 가족끼리, 혹은 학교에서 수학여행으로 가본적이 있지만 후쿠오카를 가본적이 없어서... 후쿠오카를 고른 것 같습니다. 아무생각없이 골랐는데, 생각보다 볼거리와 먹거리가 엄청 풍부한(?) 도시라서 깜짝놀랐어요 ㅋㅋ

예전에 비해서 일본의 엔화의 환율이 많이 떨어졌던 것도 한 몫을 했습니다. 요즈음 또 슬슬 오르고 있는 추세라 이번에 가 보는게 좋을 것 같았습니다.



숙소 정하기


여행을 간다면, 제일 먼저 생각하게 되는 몇가지 중 한가지입니다. 혼자서 자유여행을 가는건 처음이라, 숙박을 처음에 어떻게 할지 고민을 했습니다. 게스트하우스나 호텔, 캡슐호텔 등 다양한 방법이 있었는데요, 이번 여행에서는 이왕 돈 많이써서 해외를 나가기로 한 만큼, 편리함을 추구하여 호텔에서 숙박을 하기로 하였습니다.

이제 숙박업소의 종류는 정해졌는데, 이를 어떻게 예약을 해야되나.. 우선 게스트하우스가 아니라 평소 많이 애용하던 AirBnB를 사용할 수 없게되어 다른 방법을 찾아야했습니다. 여러 검색 끝에 찾은 몇개가 있었는데요, 저는 그 중에 Booking.com이라는 사이트를 사용했습니다.


도시별로 체크인/체크아웃 날짜를 설정하고, 숙박 인원을 기입해주면 숙박할 수 있는 호텔을 리스팅 해주는 방식인데요, 가격 범위를 정하거나 옵션등을 추가로 넣어서 검색이 가능합니다. 신용카드 정보만 기입을 해 놓고, 나중에 현지에 도착해서 현금으로 결재가 가능했고요, 예약/취소 가 간단해서 사용하기 좋습니다.

이번 여행에서 저는 booking.com을 이용하여 Nishitetsu Inn Fukuoka 라는 호텔을 잡았습니다. 우선 가격이 다른 호텔들에 비해서 굉장히 저렴했고요, 지하철 역 (텐진역), 캐널시티 등의 장소와 가깝고 나름 후쿠오카 시의 중심지 쪽에 위치하여 교통이 좋을 것 같아보여 이 호텔로 결정하였습니다.

실제로 묵으면서도 불편한점이 없었고, 직원분들도 영어를 잘 하셔서 불편한 점 없이 잘 지내다 왔습니다. 저희가 예상했던 그대로, 교통편은 정말 최고였습니다. 만약 후쿠오카에 여행을 가시는 분이 계신다면, 이 호텔을 추천해드리고 싶습니다 :) 

참고로 가격은 4박 5일에 26,800엔, 지금 환율로 따질때 약 27만원 정도였습니다. 두명이서 4박에 27만원이였는데 호텔치고는 나쁘지않았던 것 같습니다.

후쿠오카 숙소를 정할 때 고려 할 점
    • 교통편 - 대중교통, 터미널, 중심지 등과의 거리
    • 가격 - 너무 비싸도 안되겠죠?
    • 직원 - 영어/한국어 가능한 직원
    • 후기 - 커뮤니티나 호텔 예약 사이트에서의 후기


항공편 구하기


숙소 다음으로 생각해야 될 것은 바로 항공편입니다. 사실 후쿠오카/나가사키 지역의 경우, 굳이 항공편이 아니여도 되긴 합니다만! 보통은 비행기를 이용하기도 하고, 저 역시 이번에는 비행기를 이용하였기 때문에 항공편에 대해서만 이야기하겠습니다.


항공편같은 경우도, skyscanner를 사용했습니다. 나름 쉬운 UI를 가지고 있어서 사용하는데 무리는 없었던 것 같습니다. 나름 메이저항공사들(대한항공, 아시아나항공 등)들과 저가항공(진에어, 제주항공 등) 검색이 다 되어서 좋은 것 같습니다.

물론 땡처리나 급하게 처리하는 항공권을 여행일정 얼마 전에 구입하는 것도 가능하겠으나, 제가 회사에 다녀서 일정을 확정을 한상태로 가버리는 바람에 그냥 Early bird로 티케팅을 하기로 하였습니다.

결국엔 제주항공을 타게되었는데요, 인천 출발 15:30분 비행기와 후쿠오카 출발 17:50 비행기를 탔습니다. 항공기 시간대가 잘 맞아서 출발할 때는 오전 반차로 사용 휴가를 줄일 수 있었고, 돌아오는 비행기 시간도 오후라서 점심먹고 시내 구경을 좀 하다가 올 수 있었습니다.

제주항공을 이용해서 후쿠오카를 갈 땐 위탁수하물 15kg 1개가 무료로 가능합니다. 15kg 무게맞춰주는게 은근 힘들더라고요... 후쿠오카에서 돌아올 때는 18kg으로 3kg를 초과해서... 아쉽지만 술을 버리고 왔습니다 ㅠㅠ


후쿠오카의 대중교통 및 패스와 열차 예매


to-be-added



목차

1. TCP/IP network stack 간단 소개 및 정리

2. Ack Sending Mode 란?

3. Delayed Ack & Quick Ack 소개, 차이점

4. Linux 코드에서는 어떻게 구현이 되어있는가? 코드 분석

5. 관련 RFC


이번에 공부하며 알게된 리눅스 커널의 Ack Sending Mode에 대해서 정리도 할겸, 이렇게 블로그 포스트를 남겨봅니다. 



TCP/IP Network Stack에서의 ACK


TCP 통신에서는 "신뢰성"을 가장 최우선에 두고 통신을 합니다. 때문에 UDP같은 프로토콜과는 달리 패킷이 수신자(받는이)에게 잘 도착하였는지, 또는 중간에 유실은 되지 않았는지 확인하는 기능과 옵션들이 있는데요, 이중의 대표적인 기능중 하나가 바로 "Ack 에 기반한 통신"입니다. TCP에서는 수신자에게 보낸 payload data(데이터)에 대한 Ack(Acknowledgement)을 받아야 정상적으로 데이터가 수신자에게 도착을 하였다고 판단합니다. 만약 Ack 이 돌아오지 않는다면 송신자(보낸이)는 수신자가 해당 payload data를 받지 못했다고 판단하고 retransmit(재전송)을 합니다.


때문에 TCP 프로토콜에서는 ACK이 굉장이 중요한 역할을 해주고 있으며, 안정적인 통신을 할 수 있도록 도와주는 기능입니다. 초창기 TCP의 경우, 수신자는 받은 payload data에 대해서 모두 Ack을 보냈었습니다. 그 당시에는 end-point 장비들도 많지 않았고, 유저수도 적었기에 별 문제없이 가능했었지요. 하지만 지금의 네트워크 현황을 본다면, 수신자가 받은 payload data마다 Ack 패킷을 보낸다면, 한정된 대역폭(bandwidth) 자원을 많이 사용하게 되어서 데이터를 보내고 받는데 더 오랜 시간이 걸리게 됩니다. 그리고 이 문제를 해결하고자 나온 기능이 바로 Delayed Ack 입니다.



Ack Sending Mode란?


Ack Sending 이라는 단어가 굉장히 생소하실 수 있는데, 사실 이건 제가 그냥 붙인 용어입니다. 따로 기술용어가 존재하는지는 모르겠지만, 제가 따로 존재 할 수도 있는 그 용어를 찾기 전까지 이 포스트에서는 Ack Sending은 말 그대로 TCP에서의 Ack을 보내는 방식을 일컫는 용어입니다. 



Delayed Ack & Quick Ack


Delayed Ack은 사실 널리 알려져있습니다. RFC 문서에도 명확한 수식은 없으나, Delayed Ack 관련 내용이 나와있고, 대부분의 운영체제에서 Delayed Ack을 채택하여 쓰고있습니다. 얼마나 "Delay"를 주는지는 운영체제별로, 또 커널별로 다르지만, 확실한건 받은 payload마다 ack을 보내는 방식보다는 많이 선호되어서 사용되고 있다는 점입니다.

Delayed Ack은 timer에 기반하여 동작합니다. delayed ack timer를 사용하는데, payload를 받은 이후에 timer가 돌기 시작하고 expire, 즉 timeout이 되면 server쪽에 그동안 받은 payload들에 대한 ack을 보내주는 것 입니다. 코드에 따라서 timer 기반이 아닌, 받은 payload 패킷 기반으로도 delayed ack을 구현 할 수도 있습니다. 한 예로, "10개의 payload data를 받으면 ack을 보낸다"가 있습니다.

Quick Ack의 경우 많이 알려지지 않았고, 생각보다 기술문서도 찾기가 힘듭니다. RFC에는 당연히 나와있지 않고요 (Quick Ack이 아닌 다른이름으로는 있을 수 있겠네요). 오래전의 TCP에서 사용되었던 방식이고, 현대에는 대역폭 자원을 많이 낭비한다는 이유때문에 잘 쓰이지 않습니다. 하지만, 1:1 즉각대응 ack을 보낸다면, window size를 빠르게 업데이트 할 수 있다는 장점이 있습니다.

TCP에서 처음 연결을 시도 할 때, 3 way handshaking을 한 후에는 window size를 보고 패킷을 조금씩 보냅니다. 혼잡제어 측면에서 보았을때는 Slow-start 구간으로 볼 수 있습니다. 점차적으로 보내는 패킷을 늘리는 구간인데요, 만약 이 구간에서 Quick Ack을 사용하여 1:1로 ack을 보내면 빠르게 window size를 키운상태에서 통신을 할 수 있습니다. 이는 속도측면에서 큰 향상이 될 수 있습니다.



Linux Kernel 코드의 Ack Sending은?


to-be-added



관련 RFC 문서


RFC 1122 - Requirements for Internet Hosts - Communication Layers


'Development > Linux & Kernel' 카테고리의 다른 글

systemd 관련 문서  (0) 2018.11.15
Linux Booting Process  (0) 2018.11.15
Linux Kernel's Ack Sending Mode  (0) 2015.09.15
Linux Crash Dump 분석하기  (0) 2015.06.01





+ Recent posts