kakasoo

여기서는 네트워크, 서버, Express.js 등을 공부하면서 내가 경험한 착각들에 대해서 설명하고자 한다. 사실, 이 대부분의 문제들은 내 안에서 이미 해소가 된 것들이다. 그러나 다른 사람들, 동기나 후배들이 과제를 하는 모습을 보면서, 다른 사람들도 내 패턴을 그대로 답습할 수 있다는 것을 느끼고, 나와 같은 실수나 착각을 반복하지 않기를 바라는 마음에서 글을 쓴다. 잘하는 사람도 있겠지만 아예 새로 시작하는 사람들도 있을 것이고, 이 문제들을 직면하고 좌절할 사람들도 있을 것이기 때문에, 작성하는 글인 만큼, 이미 안다면 넘어가도 좋을, 그저 그런 글이다. 일단 처음에 공부를 하면서 겪은 문제들은 아래와 같다. 당연히 설명할 순서도 아래와 같다. 서버라는 게 뭐지? → 서버라는 개념을 너무 거창하..

아래와 같은 내용을 다룬다. 아래 내용은 책에서 설명한 것을 그대로 따라, 이 장에서 무엇을 배울 수 있는지를 옮겨 적은 것이다. 여러 종류의 소프트웨어 및 하드웨어 웹 서버에 대해 조사한다. HTTP 통신을 진단해주는 간단한 웹 서버를 펄(Perl)로 작성해본다. 어떻게 웹 서버가 HTTP 트랜잭션을 처리하는지 단계 별로 처리한다. 또한 이해를 돕기 위해 아파치 웹 서버를 이용하는 (필요에 따라 설정 옵션도 변경해가면서) 예를 보여줄 것이다. 별도 정리 및 의문점 동일한 호스트의 반복적인 접속이 있을 경우 (클라이언트 호스트 명 식별로 파악했을 때) 차단하는 기능을 구현해보자! 리눅스에서는 이런 것도 가능하다. var child_process = require("child_process"); child..

4.6 파이프라인 커넥션 HTTP/1.1은 지속 커넥션을 통해서 요청을 파이프라이닝할 수 있다. 이는 keep-alive 커넥션의 성능을 더 높여준다. 파이프라인은 응답을 기다리지 않고 요청을 보내는(...?) 방식이다. 파이프라인에는 제약이 있다. HTTP 클라이언트는 커넥션이 지속 커넥션인지 확인하기 전까지는 파이프라인을 이어서는 안 된다. (지속 커넥션이 아니면 뒤의 요청이 무시 당한다.) HTTP 응답은 요청 순서와 같아야 한다. HTTP 메시지는 순번이 없기 때문에 응답이 순서 없이 오면 정렬할 방법이 없다. HTTP 클라이언트는 도중에 커넥션이 끊기더라도 다시 요청을 보낼 수 있어야 한다. 이 경우에는, 몇 개의 요청까지 성공했는지 확인할 방법이 있어야 한다. HTTP 클라이언트는 POST 요..

4.3 HTTP 커넥션 관리 다시 본론으로 돌아가 HTTP에 대해서 알아보자. 여기서부터는 커넥션을 생성하고 최적화하는 HTTP 기술을 설명한다. 4.3.1 흔히 잘못 이해하는 Connection 헤더 HTTP는 클라이언트와 서버 사이에 프락시 서버, 캐시 서버 등이 놓이는 것을 허용한다. 이 경우 메시지는 중개 서버들을 거쳐서 오간다. 이 때, 특정 경우에 한하여 두 대상에서만 전달할 값이 있을 수 있다. 예컨대, HTTP Connection 헤더 필드는 커넥션 토큰을 쉼표로 구분하여 갖고 있는데, 그 값들은 다른 커넥션에 전달되지 않는다. 이 때 Connection: close 라고 명시할 수 있다. Connection 헤더에는 다음 세 가지의 토큰이 전달될 수 있다. HTTP 헤더 필드 명은 이 커..

보는 것이 용이하도록, 앞의 내용과 겹쳐서 썼습니다. 4.2 TCP의 성능에 대한 고려 HTTP의 성능은 TCP 바로 위 계층이라 TCP 성능에 영향을 받는다. TCP 커넥션을 이해하면 HTTP 커넥션 최적화 요소를 더 잘 알게 되고, 성능을 높일 수 있다. 4.2.1 HTTP 트랙잭션 지연 HTTP 트랙잭션 과정은 DNS 찾기, 연결, 요청, 처리, 응답, 종료의 단계를 거치는데, 이 중 처리의 시간은 요청 및 응답의 전송에 비하면 상당히 짧은 시간에 이루어진다. 따라서 서버가 너무 큰 데이터를 내려받거나 복잡한 동적 자원을 실행하지 않는 한, 대부분의 HTTP 지연은 TCP 네트워크 지연 때문에 발생함을 알 수 있다. HTTP 트랜잭션을 지연시키는 원인은 여러 가지가 있다. 클라이언트는 URI에서 웹..

HTTP 명세에는 HTTP 메시지에 대해서 자세히 설명하고 있지만 HTTP 커넥션에 대해서는 설명하고 있지 않다. 하지만 HTTP 애플리케이션을 만드려면 HTTP 커넥션 역시 잘 알고 있어야 한다. 이 장에서는 아래와 같은 내용을 배운다, HTTP는 어떻게 TCP 커넥션을 사용하는가. TCP 커넥션의 지연, 병목, 막힘 병렬 커넥션, keep0alive 커넥션, 커넥션 파이프라인을 활용한 HTTP의 최적화 커넥션 관리를 위해 따라야 할 규칙들 별도 정리 및 의문점 이번에는 이 단락을 활용하여, 밑의 내용을 공부해본 사람들에게 질문을 던지도록 하겠다. 패킷이란 무엇인가? HTTP의 네트워크 프로토콜 스택과 HTTPS의 네트워크 프로토콜 스택을 구분하여 설명하고, 그 차이를 말하라. 4.1 TCP 커넥션 H..

3.5 헤더 헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해서 함께 사용된다. 헤더는 특정 종류의 메시지에만 사용할 수 있는 헤더와, 일반 목적으로 사용하는 헤더, 응답과 요청 양쪽 모두에서 정보를 제공하는 헤더가 있다. 헤더는 크게 다섯 가지로 분류한다. 일반 헤더 (General Headers) : 클라이언트와 서버 양쪽이 모두 사용하는 헤더. 어딘가에 메시지를 보내는 다른 애플리케이션을 위해 다양한 목적으로 사용된다. 예를 들어 Date 헤더가 있다. 요청 헤더 (Request Headers) : 요청에서 사용하는 헤더. 클라이언트가 받고자 하는 데이터 타입이 무엇인지와 같이, 부가 정보를 제공한다. 응답 헤더 (Response Headers) : 클라이언트에게 정보를 제공하기 위한..

3.4 상태 코드 상태코드는 5가지 범주로 나뉜다. 즉, 앞자리가 1부터 5까지 있다고 보면 된다. 상태 코드는 명확하다, 여기에 사유 구절이 들어가면 클라이언트가 트랙잭션을 이해하기 편해진다. (사유 구절은 공식적인 가이드가 없다.) 3.4.1 100-199: 정보성 상태 코드 HTTP/1.1 에서 도입된 것으로 비교적 최신의 것이며, 가치에 대해서는 아직 논란이다. 상태코드 100 사유구절 Continue : 요청의 일부가 받아들여졌고, 클라이언트는 나머지 요청을 보내야 한다는 의미이다. 이것을 보낸 후에는 서버는 반드시 요청을 기다려야 한다. 만들어진 의도는, 클라이언트가 본문을 전송하기 전에 서버가 받아들일 것인지에 대한 확인을 최적화하기 위한 용도였으나, 프로그래머를 혼란스럽게 하는 경향이 있다..

3.2 메시지의 각 부분 HTTP 메시지는 단순히 구조화된 블록이다. 각 메시지는 클라이언트로부터 요청, 서버로부터의 응답 중 하나를 포함한다. 메시지는 시작줄, 헤더 블록, 본문, 이렇게 세 부분으로 되어 있다. 시작줄은 이것이 어떠한 메시지인지에 대한 메타 정보를 담고 있고, 헤더 블록은 속성을, 본문은 데이터를 담고 있다. 본문은 없을 수도 있다. 시작줄과 헤더의 구분은 사실, 그저 캐리지 리턴과 개행 문자로 구성되어 있다. 다만 오래된 HTTP 어플리케이션이나 잘못 만든 HTTP 어플리케이션은 개행문자만으로 되어 있어 있는 경우도 있으니 그냥 개행문자만도 처리할 수 있어야 한다. HTTP/1.0 200 OK // 시작줄 Content-type: text/plain // 헤더 Content-Leng..

메시지가 어떻게 흘러가는가 HTTP 메시지의 세 부분 (시작줄, 헤더, 개체 본문) 요청과 응답 메시지의 차이 요청 메시지가 지원하는 여러 기능(method) 응답 메시지가 반환하는 상태 코드(status code) 여러 HTTP 헤더들은 무슨 일을 하는가 별도 정리 및 의문점 entity란 무엇인가? https://linuxism.ustd.ip.or.kr/45 안전한 메서드의 목적 (61p)이 정확히 무엇인지 이해가 가지 않습니다. PUT : 요청의 본문을 가지고, 요청 URL의 이름대로 새 문서를 만들거나 교체하도록 하는 것이다. → 이 말의 의미가, PUT 메서드의 REST한 의미에 더 부합하는 것인지? 3.1 메세지의 흐름 HTTP 메시지는 HTTP 애플리케이션 간에 주고 받는 데이터 블록 으로,..

www.notion.so/kakasoo/1-2ebc8cbd7384425ca9d55e3683ba0ba3 1. 기본 코딩 컨벤션 이 컨벤션은 NHN과 Toast의 컨벤션을 보고 정리한 것입니다, 둘은 NHN 계열의 자료로, 전자는 2009년, 후자는 2019년에 정리된 문서입니다. www.notion.so 이 컨벤션은 NHN과 Toast의 컨벤션을 보고 정리한 것입니다, 둘은 NHN 계열의 자료로, 전자는 2009년, 후자는 2019년에 정리된 문서입니다. 문서의 맨 마지막 참고자료에 두 컨벤션을 게시하였습니다. 기본 코딩 컨벤션 네이밍 규칙 이름은 소문자, 숫자, 언더스코어(_)의 조합으로 작성하며, 시작은 소문자로만 작성한다. id 및 class 네이밍 규칙 PC 화면에서의 HTML을 작성할 때에는 아래..

URL 문법 URL로 모든 리소스를 찾을 수 있지만, URL 문법은 스킴에 따라서 달라진다. 단, 대부분의 URL은 일반 URL의 문법을 따르기에 서로 다른 스킴도 형태와 문법이 매우 유사하다. 여기서 말하는 대부분의 URL 스킴은, 일반적으로 아래의 9가지 문법을 따른다. 스킴 : 서버에서 리소스를 가져오기 위해 사용해야 하는 프로토콜, 즉 방법. 사용자 이름 : 몇몇 스킴은 리소스에 접근하기 위해 사용자 이름을 필요로 한다, 기본 값으로 “annoymous”를 가진다. 비밀번호 : 사용자의 비밀번호를 가리키며, 사용자 이름에 콜론으로 이어서 기술한다. 호스트 : 리소스를 호스팅하는 호스트 명이나 IP 주소. 포트 : 리소스를 호스팅하는 서버가 열어 놓은 포트 번호, 많은 스킴이 기본 포트를 가지고 있..