일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 타입 챌린지
- 가천대
- typescript
- type challenge
- 크롤링
- 레벨 1
- 프로그래머스
- Crawling
- dp
- 문자열
- HTTP 완벽 가이드
- 쉬운 문제
- 알고리즘
- 수학
- 소켓
- dfs
- 자바스크립트
- BFS
- Nestjs
- 그래프
- ip
- Algorithm
- HTTP
- 백준
- TCP
- Node.js
- 타입스크립트
- 프로그래머스 레벨 2
- socket
- javascript
- Today
- Total
목록전체 글 (499)
kakasoo
웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치다. 웹 요청이 캐시에 도착했을 때, 사본이 존재한다면 서버에 갈 필요없이 즉시 반환한다.네트워크 요금으로 인한 비용을 줄여준다.네트워크 병목을 줄여준다.원 서버에 대한 요청을 줄인다, 즉 부하를 줄여서 전체 속도를 빠르게 해준다.거리로 인한 지연을 줄여준다.이 장에서는 캐시가 어떻게 성능을 개선, 비용을 절감하는지, 그리고 그것을 어떻게 측정하는지, 캐시가 있을 가장 적절한 위치는 어디인지에 대해 말할 것이다.또한 HTTP가 어떻게 캐시된 사본을 신선하게 유지하는지, 캐시와 서버와의 상호작용은 어떻게 이뤄지는지를 이야기한다.7.1 불필요한 데이터 전송복수의 클라이언트가 똑같은 문서를 위해 서버에 접근할 때, 서버는 각각 한 번씩 클라이..
웹 프락시 서버는 중개자다. 클라이언트와 서버 사이에서 중개하는 역할을 한다. 이 장에서는 프락시 기능과 동작을 포함한, HTTP 프락시의 모든 것을 배운다. HTTP 프락시와 웹 게이트웨이의 비교 프락시의 활용법 프락시의 실제 네트워크에서의 배치와 트래픽이 프락시 서버로 가는 과정 브라우저에서의 프락시 설정 HTTP 프락시 요청과 서버 요청의 차이, 프락시가 브라우저 동작을 바꾸는 과정 프락시 서버들을 통과하는 메시지의 경로를 Via 헤더와 TRACE 메서드를 통해 기록하는 법 프락시에 기반한 HTTP 접근 제어 프락시가 클라이언트와 서버 사이에서 다른 기능과 버전들을 지원하는 원리 6.1 웹 중개자 프락시는 클라이언트 사이에서 서버와의 트랜잭션을 중개하는 역할을 한다. 프락시가 없으면 클라이언트는 서..
여기서는 네트워크, 서버, 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 : 요청의 일부가 받아들여졌고, 클라이언트는 나머지 요청을 보내야 한다는 의미이다. 이것을 보낸 후에는 서버는 반드시 요청을 기다려야 한다. 만들어진 의도는, 클라이언트가 본문을 전송하기 전에 서버가 받아들일 것인지에 대한 확인을 최적화하기 위한 용도였으나, 프로그래머를 혼란스럽게 하는 경향이 있다..
조금 문학적인 표현을 가미하자면, 챌린지 때는 시시포스의 신화처럼 고통스러웠다. 오늘 하루 내가 잘했든 못했든 내일 새로운 문제가 굴러들어왔다. 엎친 데 덮친 격으로 문제를 풀면 멘탈이 남아나지 않기 때문에, 스스로가, 어제와 오늘이 완전히 별개의 것인 양 여기지 않으면 안 됐다. 마치, 오늘 챌린지를 시작한 것 마냥 깔끔한 정신으로 임해야 했다. 그런 반면 멤버십은 매우, 자유로웠다. 기본적으로 2주일의 시간동안, 첫 주에는 백엔드 두번 째 주에는 프론트를 하면 됐다. 난이도만 놓고 보면 챌린지와 유사했음에도 하루 간격이었던 기간이 2주로 늘어남에 따라, 기간이 무척 길어진 것 때문에 상대적으로 편안한 분위기에서 할 수 있었던 듯 하다. 1주차 때 나는 HTML, CSS를 다룰 줄 몰랐다. 물론 읽을 ..
3.2 메시지의 각 부분 HTTP 메시지는 단순히 구조화된 블록이다. 각 메시지는 클라이언트로부터 요청, 서버로부터의 응답 중 하나를 포함한다. 메시지는 시작줄, 헤더 블록, 본문, 이렇게 세 부분으로 되어 있다. 시작줄은 이것이 어떠한 메시지인지에 대한 메타 정보를 담고 있고, 헤더 블록은 속성을, 본문은 데이터를 담고 있다. 본문은 없을 수도 있다. 시작줄과 헤더의 구분은 사실, 그저 캐리지 리턴과 개행 문자로 구성되어 있다. 다만 오래된 HTTP 어플리케이션이나 잘못 만든 HTTP 어플리케이션은 개행문자만으로 되어 있어 있는 경우도 있으니 그냥 개행문자만도 처리할 수 있어야 한다. HTTP/1.0 200 OK // 시작줄 Content-type: text/plain // 헤더 Content-Leng..