systemd는... 넘나.. 방대한것

http://fmd1225.tistory.com/93


https://www.freedesktop.org/wiki/Software/systemd/

https://www.freedesktop.org/software/systemd/man/systemd.unit.html

https://www.freedesktop.org/software/systemd/man/systemd.service.html


'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

리눅스 운영체제의 부팅 프로세스를 정~~말 잘 정리한 문서 


https://www.ibm.com/developerworks/community/profiles/user/yates


'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

간단하게 여기저기서 찾은 정보를 모아두는 포스트


Scapy의 Tx 함수들에 대한 설명과 차이점

http://abunchofbaloney.blogspot.com/2014/09/scapy-send-vs-sendp.html

https://scapy.readthedocs.io/en/latest/usage.html?highlight=sr


짱짱 느린 Scapy의 Tx 속도를 개선시킬 수 있는 방법

https://home.regit.org/2014/04/speeding-up-scapy-packets-sending/comment-page-1/


Scapy 중요한거만 간단하게 정리된 문서 by SANS

https://www.itlkorea.kr/data/scapy-pocket-guide0.2.pdf


Scapy로 패킷 쐈을 때,  RST 나가는 현상

https://stackoverflow.com/questions/24180654/scapy-send-packet-getting-rst

- iptables 에 예외처리 필요

'Development > Python' 카테고리의 다른 글

Python Scapy 라이브러리 관련 정보  (0) 2018.11.08
[Django] Django 배워보기 #1  (0) 2016.06.16

Linux 환경에서 Dummy File 생성 방법과 성능 비교


회사에서 하는 업무가 업무인지라 주로 리눅스 환경에서 개발/테스트를 하는데, 이 때 테스트 파일을 특정 용량별로 생성해야 하는 경우가 있습니다. 해서 매번 dummy file 생성 방법에 대해서 구글에 검색해서 만들고는 했는데, 오늘 문득 '과연 어떤 명령어가 가장 빠르게 dummy file을 생성할까?' 라는 생각이 들었습니다. 하여 오늘은 리눅스 환경에서 dummy file을 만드는 방법들을 소개하고, 어떤 명령어가 가장 빠르게 파일을 만들어 주는지에 대한 비교 글을 적어볼 생각입니다.


생성 속도와 성능 측정 방법

- 테스트 머신 : 제 개인 개발머신 (가상머신; 1 가상코어, 500M 램)

- time 명렁어를 이용한 속도/성능 측정

- 1024byte, 100K, 100M, 1G 파일을 2개씩 생성 (총 8개)

- 테스트 스크립트 :

- dd :  test.sh

- truncate :  test_truncate.sh

- falocate :  test_fallocate.sh




Linux 환경에서 Dummy File 생성하기 - "dd" 명령어


사실 개인적으로 전 dd를 별로 좋아하지 않습니다. 이유는 그냥 느린 것 같다는 기분이 들어서... 헌데 블로그들을 찾아보면 dd를 가장 많이 사용하시는 것 같습니다. dd 명령어는 테스트용 더미파일을 만드는 것 외에도 iso를 USB에 넣어서 부팅 USB를 만들때도 사용하는 등, 리눅스 환경에서 개발을 하거나 서버를 운용한다면 굉장이 많이 쓰는 명령어입니다.


사용법 : [email protected]# dd if=/dev/zero of=파일위치 bs=1 count=0 seek=크기

예시 : [email protected]# dd if=/dev/zero of=./1G bs=1 count=0 seek=1G


파일 위치는 그냥 생성할 더미파일의 위치와 파일명을 적어주시면 되고, 크기는 G/M/K 단위도 입력이 가능하며 단위 없이 숫자만 적을 경우 자동으로 byte로 인식합니다.


성능 측정 결과




Linux 환경에서 Dummy File 생성하기 - "fallocate" 명령어


fallocate 명령어는 dd 명령어에 비해서는 굉장히 외우기도 쉽고 사용하기도 간편합니다.


사용법 : [email protected]# fallocate -l 크기 파일명

예시 : [email protected]# fallocate -l 1G 1G-test.file 


dd 명령어와 동일하게 크기는 G/M/K 단위도 입력이 가능하며 단위 없이 숫자만 적을 경우 자동으로 byte로 인식합니다. 파일명은 원하시는 더미파일 경로와 이름을 적어주시면 됩니다.


성능 측정 결과




Linux 환경에서 Dummy File 생성하기 - "truncate" 명령어


마지막으로 제가 자주 사용하는 truncate 명령어입니다.


사용법 : [email protected]# truncate -s 크기 파일명

예시 : [email protected]# truncate -s 1G 1G-test.file


fallocate 명령어 사용법은 완벽하게 동일합니다.


성능 측정 결과




결론...?


CPU 사용률은 정확하지 않으니 실행 시간으로만 보았을 때, dd와 truncate가 비슷하였고, fallocate 명령어만 유난히 시간이 오래 걸린 것을 확인 할 수 있습니다. 일단 생각보다 dd가 느리지 않다는 것이 제일 충격이네요. 저는 쓰던대로 truncate 쓰면 될 것 같습니다 :)


이 테스트 결과는 측정 환경이 완전 무결하지 않고, 개인 서버에서 임의로 테스트 해 본 결과이므로, 참고만 하시고 진지하게 받아들이시기보다는 가볍게 보시는걸 추천드립니다!



Reference


https://zetawiki.com/wiki/리눅스_대용량_파일_생성

https://stackoverflow.com/questions/257844/quickly-create-a-large-file-on-a-linux-system


문제 현상


git 명령어를 터미널에서 사용하려고 했을 때, 아래와 같은 로그가 터미널에 출력되고 명령어는 실행되지 않는다.

➜  ~ git

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun


해결 방법


아래의 명령어로 xcode command line developer tools를 설치해주면 된다.


➜  ~ xcode-select --install

xcode-select: note: install requested for command line developer tools


문제 원인


아마 이번에 시스템 업데이트 (엘케피탄 -> 시에라)를 하면서 무언가 잘못 된 것 같은데... 확실한건 xcode를 통해서 관련 패키지(?)를 재설치 해 주면 된다.

※ 주의 ※

이 글은 작성자가 저장을 하지 않은 상태로 날린 후에 재작성한 글이라 작성자의 멘붕이 부분적으로 반영되어있을 수 있습니다.


Hello Node.js!


왜 이놈은 Django는 첫포스팅 후 아무것도 안써놓고, 다른 언어 포스팅을 시작하지? 라고 생각 하실수도 있는데, 어쩌다 보니 그렇게 되었네요 허허허 회사 팀에서 스터디를 하는 바람에... 아무튼! 이번에는 일전에 포스팅 하였던 Django와는 약간 다른, Node.js에 대해서 공부를 시작하게 되어서 이렇게 새로운 포스팅을 하기로 되었습니다. 아쉽게도 Django는 조금 미뤄둘 것 같네요 ㅠㅠ 그래도 Node.js와 Django는 올해안에 끝내는 것이 오늘의 목표입니다 :)


그럼 Django를 뒤로 미루고버리고 Node.js를 택한 이유는 무엇인고 하니, 위에 살짝 언급한대로 회사 팀 내에서 스터디를 진행하게 되었습니다. 여기에 추가로 개인적으로 "시각적"으로 보여 줄 수 있는 산출물을 만들 수 있는 언어를 배워보고 싶었던 욕망이 조금 있었습니다. 회사에서 다루는 언어는 C, Python, Shell Script 이렇게 3개 언어가 다고, 시각적으로는 로그 이외에는 볼 수 없는 CLI 환경에서 개발하다 보니, 시각적 산출물에 대한 니드가 개인적으로 생겼습니다. 해커톤이나 경진대회, 공모전 등에도 어플이나 웹을 짤 수 없으면 거의 참가가 힘들 것 같더라고요. 그래서 조금씩 회사에서 쓰는 커널레벨이 아닌 유저레벨 단에서의 무언가도 좀 해보려고 이번에 Node.js를 배워보게 되었습니다.


Node,js를 배우기 위한 주 교제는 책으로 진행을 할 예정이고, 조금씩 추가자료가 필요하면 인터넷으로 검색 할 예정입니다. 책은 팀 스터디에서 아래의 책을 선정하여 챕터별로 개인 조사 후 발표를 스터디 운영방법으로 정해서, 제 개인 공부도 저 책을 주로 공부 할 예정입니다.


< Node.js 프로그래밍 :: 모던 웹을 위한, Node.js LTS 버전으로 배우는 웹 애플리케이션 서버 프로그래밍 >

Link : http://book.naver.com/bookdb/book_detail.nhn?bid=10756354



About Node.js!


Node.js는 도대체 뭣하는 녀석일까요? 사실 저도 잘 몰라요. 왜냐고요? 저도 Node.js책을 연지 아직 한시간이 안되었기 때문이죠... 사실 책을 펴기 전까지는 그냥 자바스크립트를 쓰는 것..? 웹사이트 만들 수 있는 것? 이런 언어의 한 종류로만 알고 있었습니다. 이걸로 무엇을 만들 수 있는지, 혹은 어떤 문법을 쓰는지, 내부동작은 어떻게 되는지 모두 몰랐던 상태였습니다. 책을 보니까, 특별히 강조 할 만한 내용은 "Node.js는 "스레드를 사용한 동기방식이 아닌, 이벤트를 사용하는 비동기 방식" 이라는 것을 알고가면 좋을 것 같네요. 그 외에는 아무 Node.js 책 1장을 보시면 나와있을 것이라고 생각됩니다 :)



Node.js로 개발하기!


Node.js 개발환경도 저는 [Django] Django 배워보기 #1에서 했던 방법과 비슷하게 진행 할 예정입니다. AWS에 있는 개인 개발환경에서 개발을 하고, AWS에 있는 배포환경에 배포를 할 예정입니다. 배포환경은 앞으로 http://node-test.dry8r3ad.com 에 할 것 같습니다, 개발/배포를 위한 AWS 환경 세팅을 자세하진 않지만 간략하게 보고싶으신 분들은 [Django] Django 배워보기 #1 포스트를 확인해주세요. 제가 산 책에서도 별도 이야기가 없는 것으로 보아, Node,js는 Python의 PyCharm같은 언어에 최적화된 에디터/IDE가 없는 것 같네요. SSH로 붙어서 VIM 에디터로 개발을 하겠습니다!


  1. 김인수 2018.10.09 12:09

    안녕하세요 맨파워코리아 헤드헌팅 본부 김인수입니다.
    혹시 주변에 nodeJS 사용경력 5년이상이고 나이는 80년생이하신분 추천해 주실만한 사람은 없는지요?
    포지션은 백엔드개발(NodeJS)이며 블럭체인 최고 회사입니다.
    연봉은 1억~2억 가능하시고 연봉 및 처우조건은 아주 좋습니다.
    답변 부탁 드립니다. 감사합니다. (김인수, [email protected])

Hello Django!


참으로 오랜만에 개발 관련 포스팅을 하는 것 같네요. 요즘 제가 바람이 들었나... Low-Level 쪽만 하다가 갑자기 뭔가 보여줄 수 있는 프레임워크나 언어를 다루고 싶어졌습니다. 하여 열심히 찾아보다가, 요즘 대세인 Python 기반의 웹 프레임워크인 Django를 배우기로 하였습니다!


사실 뭔가를 열심히 배워봐야지! 라는 마음보다는 오랜만에 프론트단을 좀 접해볼까? 이런 느낌이라서 시작은 방대하나 끝은 미약 할 수 있습니다. 그래도 하는 동안에는 열심히 블로그에 포스팅을 하려고 합니다. 이런거라도 해야 개발자가 운영하는 블로그같을 것같네요.. 사실 요즘 대세가 Python이라서 이를 배울 겸, 프론트를 할 겸, 뭔가 웹으로 만들어야 할것도 있고, 주변에 문과친구가 갑자기 Django로 웹사이트 만드는 걸 보고 충격받아서(?) 배우려고 하고 있습니다. Python 언어 학습도 주 목표 중 한가지라, Django랑 Flask 중에서 굉장히 많은 고민을 했는데, 그냥 뭔가 좀 더 자주 들어보았던 것 같은 Django를 선택하여 하게되었습니다 ㅋㅋㅋ 



개발을 시작해봅시다.


그냥 개인적으로 개발 공부하고? 취미로 찾아보는 것들을 기록하는 공간이니, Django가 무엇이고, 역사와 어떻게 생겼는지는 다루지 않겠습니다. 다른 블로그에도 많고, 무엇보다 장고걸스 서울[각주:1]에서 열심히 번역해주신 한글판 튜토리얼이 너무나도 잘되어있습니다. 짱이에요 bb 저도 저거보고 공부할겁니다 :)


Django Tutorial (Korean)


Django를 처음 접하시는 분들이라면 꼭 한번정도는 돌아주시는 것이 좋을 것 같아요. 저도 튜토리얼 따라하면서 조금씩 공부르 하고있습니다! 한글번역판을 만들어주신 장고걸스 커뮤니티분들에게 감사드립니다 (_ _)



개발환경 고민하기


음... 전 사실 로컬에서 개발하는 것을 좋아하지 않습니다. 회사업무때문에 개발을 제 로컬 데스크톱에서 했다가 날려먹은적이 신입사원 때는 꽤 있었거든요. 그래서 전 모든 개발을 AWS 환경에 개발서버 하나를 만들어놓고 했습니다. 이번 Django도! 가능 할지는 모르지만... 그렇게 진행 할 예정입니다.


사용할 IDE : PyCharm

개발 환경 : AWS EC2, Python 3

배포 환경 : AWS Beanstalk, Python 3


AWS, Python 3, Django 3개에 대해서 마스터 할 수 있겠네요 ㅋㅋㅋㅋㅋ 사실 개발서버에서 바로 배포도 할까.. 싶었지만! 개인 개발이면 모르지만 나중에 정말 큰프로젝트를 진행하거나 회사에서 이 기술을 사용한다면 실제 개발서버와 배포서버가 다를 것이란 점을 조금 염두에 두고, 클라우드 가상화 기술을 좀 활용해 보고자 이렇게 환경을 계획하였습니다.



AWS에 개발환경 세팅하기


사실 AWS에 개발환경 세팅하기라고 거창하게 말해도, 결국에는 그냥 리눅스 머신 하나 만드는 것 뿐입니다 ㅋㅋㅋ 빌드머신 겸 개발서버라고 하지요... 이번 포스팅에서 다루는 Django는 Python 기반의 웹프레임워크이므로, 그냥 파이썬만 깔려있으면 됩니다. 주의하실점은, 2.x 버전인지 3.x 버전인지는 꼭! 확인해주세요. 문법적으로도 그렇고, 꽤 큰 차이가 있는 걸로 알고있습니다.



AWS 관리 콘솔에 처음 접속하면, 위와 같은 창이 뜹니다. 뭔가 엄청 많지요? 다 AWS에서 실행/사용 할 수 있는 서비스들입니다. 개발머신의 경우에는 이중에서 EC2를 사용합니다.


EC2를 새로 런청하는데, OS는 free tier 중에서 Ubuntu로 선택해서 진행해주시면 됩니다. 이 이후에 개발/빌드 머신 세팅은 개인 재량에 맡깁니다.. 절대로 제가 이미 개발서버가 있어서 이러는게 아니에요


그냥 Instance 하나 생성하고 Debian 계열 리눅스 하나 까는거에요! 어렵지않아요~



AWS에 배포환경 세팅하기


배포환경은 간단하게 짚고넘어갈게요. 보통 제가 일반적으로 하는 개발 분야 (Kernel Level이나 데몬 등 시스템프로그래밍 쪽)는 별도 배포 서버가 필요하지 않습니다. 회사에서는 따로 패키징을 해서 "릴리즈"라는 것을 하긴 하지요. 그럼 배포서버는 언제쓸까요? 이 포스팅은 Python 기반 "웹프레임워크 Django"를  위한 포스팅입니다. "웹"이라는 글자가 들어가죠? 이 의미는 저희가 열심히 개발한 것을 "어딘가"에는 올려서 인터넷과 연결시켜서 웹서버 역할을 하도록 해야 한다는 것입니다. 이 웹서버 역할을 해 주는 곳에 개발 완료한 코드를 올리는 행위를 "배포/Delopy"라고 합니다. 고로 간단하게 보면 웹서버가 배포서버겠죠?


이번 포스팅에서는 AWS의 Elastic Beanstalk를 사용하여 배포서버를 구성하려고 합니다. 이 Beanstalk은 EC2의 웹 어플리케이션 전용 버전이라고 보시면 됩니다. 어떤 프레임워크를 올릴 것인지 Instance를 만들 때 선택하면 해당 환경을 자동으로 만들어줍니다. 처음에는 약간 어색 할 수 있으나, 익숙해지면 매번 환경구성하는 번거로움을 덜 수 있어서 굉장이 유용합니다 bbbb




내일 이어서 포스팅!





  1. Django Girls. 장고를 하는 여성개발자 커뮤니티? 인데 IT초급자에게 장고를 배울 수 있도록 행사를 연다 카더라... [본문으로]

'Development > Python' 카테고리의 다른 글

Python Scapy 라이브러리 관련 정보  (0) 2018.11.08
[Django] Django 배워보기 #1  (0) 2016.06.16

기술 블로그?


요즘.. 이라고 할 만큼 자주 보지는 않지만, 가끔 시간이 날때 회사에서 일하기 싫어서 딴짓할 때 하는 것이 바로 다른 IT관련 회사들과 스타트업들의 기술 블로그를 보는 것 입니다. 


기술 블로그는 그 회사의 IT 개발/연구 인원들이 작성하고 관리하는 블로그로, 주로 IT 기술과 관련된 글이 올라오는 블로그입니다. 회사에서 공개한 오픈소스 프로젝트나, 개발 팀/부서 등의 조직에서 채용하고 사용하는 개발 방법론 등을 주로 한 블로그 포스트가 올라오는데요, 생각보다 좋은 기술지식을 쉽게 접하고, 제가 지금 진행하는 개인 프로젝트나 회사 업무에 적용을 할 수 있다는 이점이 있습니다. 회사마다 명칭은 다르지만, 생각보다 이런 블로그를 운영하는 회사는 많습니다.


특히 스타트업들의 기술 블로그를 보면 신기술의 트렌드, 어떤 기술이 유행하고 다루기 쉬운지, 또는 어떤 개발 방법론이 요즘은 유행을 하는지 쉽게 알 수 있습니다. 개발자라는 직업이 아무래도 평생 공부해야하는 직업이다보니, 이런 트렌드? 같은 내용도 Follow-Up 하는 것도 좋을 것 같다는 생각에 요즘 자주 들여다봅니다. 일단 제가 아는 분야의 내용의 글들이라 재미도 있고, 저 개인한테도 지식을 공부 할 수 있는 기회가 되기도하고요.



국내 회사(단체)별 기술 블로그


각 회사(단체)의 기술 블로그는 찾을 때마다 개인 기록용으로 계속 업데이트를 할 것이고, 설명도 조금씩 추가 할 계획이다.


1. VCNC의 엔지니어링 블로그 (http://engineering.vcnc.co.kr)



2. 카카오의 Tech 블로그 (http://tech.kakao.com)



3. Spoqa의 기술 블로그 (https://spoqa.github.io)



4. SK Planet의 기술 블로그 (http://readme.skplanet.com)



5. 에드투페이퍼의 엔지니어링 블로그 (http://add2paper.github.io)



6. GDG Korea의 블로그 (http://googledevkr.blogspot.kr)



7. Naver D2의 블로그 (http://d2.naver.com/home)




해외 회사(단체)별 기술 블로그


영어로 되어있지만, 읽을 수만 있다면 꽤 좋은 정보를 얻을 수 있는 블로그들이다. 


1. Facebook (https://www.facebook.com/Engineering)

2. Twitter (https://engineering.twitter.com)

3. Instagram (http://instagram-engineering.tumblr.com)

4. Tumblr (https://engineering.tumblr.com)

5. Evernote (http://blog.evernote.com/tech/)

문제의 시작


얼마전에 포스팅을 하였듯이, 기가인터넷으로 회선을 변경하고, 속도측정을 할 일이 많아서 "한국정보화진흥원"의 "인터넷 품질측정 프로그램"을 다운로드하여 사용하였습니다. 나름 정부기관인 NIA의 프로그램이고, Mac OS X도 지원을 하여 기쁜 마음에 사용을 하였습니다.

속도측정은 잘 되었는데, 문제는 속도측정을 하지 않을 때 일어났습니다.


폰트가 작아서 보이실진 모르겠지만, 위의 스크린샷은 문제상황 시의 "NSPLauncher"라는 정보화진흥원 인터넷 속도측정 프로그램 관련 프로세스들이 수십개가 떠있는 모습입니다. 아래의 명령어를 Terminal에서 실행해보시면 확인하실 수 있습니다.


ps -ef | grep NSP 


위에 스크린샷으로 찍은 프로세스들은 극히 일부로, 제가 컴퓨터 사용이 불가능하게 될 때까지는 약 800여개의 프로세스가 떠있었습니다. 


프로세스 한개가 큰 자원(CPU나 메모리)를 잡아먹는게 아니라서, top 명령어로는 확인이 불가능합니다. 수백개의 동일 프로세스가 무한으로 생기는 동안, 제 맥은 점점 느려졌고 결국에는 어플리케이션을 새로 실행시키지 못하고, 사파리에서도 새 창을 띄우지 못하고, 심지어 터미널도 정상적으로 실행이 되지 않는 현상이 나타나게됩니다. 이정도면 전국민을 대상으로한 악성 SW 유포로 봐도 무방하지 않을까.. 싶습니다. 심지어 인터넷에 검색을 해보면 예전부터 이야기가 나온 문제점이기도 하고요.


한국정보화진흥원에서는 빠른시일내에 수정을 해서 맥용 인터넷품질측정 Client를 재배포해주시거나, 다른 피해자들이 생기지않도록 맥용 프로그램만이라도 내려주셨으면 합니다.



문제 해결


보화진흥원쪽에서 새로운 SW를 배포하건 말건, 일단 내 맥을 어서 정상화 시켜주어야 겠다! 하시는 분들을 위해서 "백투더맥" 블로그에서 작년 9월쯤에 해당 내용과 해결방법을 올려주셨습니다. 저도 동일한 방법으로 진행을 했고요. 문제 해결이 필요하신 분들을 아래 링크를 눌러서 백투더맥 블로그로 이동해주세요.



번외


심심해서 이걸 어떻게하면 개발자스럽게 고칠까.. 싶어서 이미 떠있는 품질축정 SW 관련 프로세스들을 어떻게 지울까 생각하다가 그냥 쉘스크립트로 지워버렸습니다. killall 명령어를 사용하면 한번에 죽을줄 알았는데, 죽지 않아서... 800여개의 프로세스를 하나씩 pid 보면서 죽이는건 무리라 생각되어 아래 스크립트를 짜보았습니다. (어차피 저 혼자 돌릴 생각으로 바로 짠거라... ctrl+c 로 멈춰주기 전까지는 무한으로 돕니다.) 이게바로 생활코딩

ps -ef | grep NSP | wc -l 로 프로세스 값을 구한 후, for문으로 돌리는 방식도 생각해 보았으나 for 문이 돌면서 새로운 process가 뜰 가능성이 있어서 그냥 while 문으로 무한반복 하였습니다.
while true
do
        pid=$(ps -ef | grep NSP | head -1 | awk '{print $2}')
        echo $pid
        kill -9 $pid
done


  1. 북극곰스캘퍼 2016.08.17 05:58

    kill -9 $(pgrep -f NIA) 로 한번에 종료 하시면됩니다 :)


목차

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