Go Gradually - Repository

통신(파일 I/O, 네트워크I/O) 개념에서 비동기와 논블로킹 개념은 매우 혼동하기 쉬운 주제이다.네트워크를 정확히 모른다는 것은 장님이 코끼리 만지는 격이니, 이번기회에 제대로 정리하고 넘어가보자. 전제이 방식은 모두, 이 패턴을 따를 때 적용된다.호출자가 어떤 작업을 요청하고,처리자가 그 결과를 돌려준다.코드의 흐름이 동기/비동기인것은 문제에서 제외하고, 통신 개념에서의 동기/비동기에 집중해주길 바란다.코드의 흐름이 동기/비동기인 것과, 외부 서버와의 통신이 동기/비동기인 것은 문제가 발생하는 상황이 다르다.이 과정에서, 호출자의 대응 전략에 집중해보자.참고) 좌측 코드의 흐름은, 블로킹/논블로킹이 결정되지 않은 상태이다. get() 시 데이터가 준비되어 있다면 논블로킹처럼 동작할 것이고, 준비되지 ..

HTTP/2.0의 흐름제어는 뭘까?흐름 제어는 전송계층(TCP)에서 수행하는 것 아닌가?한 스트림이 커넥션을 독차지하지 않도록, 연결에 대한 전체 스트림의 리소스 배분을 수행해야 한다.이것이 HTTP/2.0의 흐름제어이다. HTTP/2.0 흐름제어와 TCP 흐름제어의 차이점항목TCP 흐름 제어HTTP/2.0 흐름 제어보호 대상- 연결 전체 (TCP 수신 버퍼)- 스트림 별- 연결 전체제어 단위- 바이트 (시퀀스 번호)- 프레임 페이로드 (바이트)주요 목적- 수신 측의 소켓 버퍼가 넘치지 않도록 전송 속도 억제- 연결 안정성 유지- 멀티플렉싱되는 여러 스트림 간 자원 경쟁 완화- 특정 스트림 일시적 쓰로틀링/우선순위 조절윈도우 크기 표기- 16-bit Window Size 필드- WINDOW_UPDATE ..

HTTP/2.0의 등장 배경HTTP/1.1은 그 구현의 단순성과 명료함, 접근성으로 많은 사랑을 받아왔고, 받고 있다.하지만, 하나의 커넥션으로 여러 요청/응답을 처리하기 어렵고, 응답을 받아야만 그 다음 요청을 보낼 수 있는 것은 분명한 아쉬움으로 남아있었다.그리하여, 다양한 곳에서 속도를 개선하기 위한 다양한 방법의 연구가 진행되었다.최종적으로, 구글의 "SPDY" 가 HTTP/2.0의 표준으로 결정되었다.하나의 TCP 커넥션에 여러 요청을 동시에 보내, 레이턴시를 줄이는 것 - HTTP 멀티플렉싱RTT가 20ms인 경우, 12.34% 성능 개선 효과를 보았다.RTT가 80ms인 경우, 23.85% 성능 개선 효과를 보았다.RTT가 200ms인 경우, 26.79% 성능 개선 효과를 보았다.HTTP/2..

글의 목적개발자가 일반적으로 사용하는 모든 TCP 네트워크 통신의 "API"인 소켓 통신의 기본 동작 원리를 이해함으로써, 추상화되어 잊기 쉬운 전송계층의 동작 원리를 "알아야 하는 부분까지" low Level 로 이해하기 위함이다.Top-Down 으로 접근하기에, 추후 전송 계층의 TCP 와 네트워크 계층의 IP까지 다룰 예정이다.서버(Server) & 클라이언트(Client) 모델우리가 컴퓨터에서 흔히 접하는 "클라이언트 & 서버" 라는 단어는 엄청 있어보이지만, 사실 실세계에서 매우 흔히 볼 수 있는 형태의 모델을 추상화해둔 패턴이다.클라이언트(Client)클라이언트는 서비스를 요청하는 쪽이다. 마치 식당에서 음식을 주문하는 손님처럼, 클라이언트는 어떤 정보를 얻거나 작업을 처리해달라고 요청하는 역..