7장 웹을 안전하게 지켜주는 HTTPS HTTP는 약점이 있다. 평문 통신이기 때문에 도청 가능 통신 상대를 확인하지 않기 때문에 위장 가능 완전성을 증명할 수 없기 때문에 변조 가능 7.1.1 평문이기 때문에 도청 가능 HTTP는 암호화 기능이 없기 때문에 평문으로 메시지를 보낸다. 따라서 통신 경로의 도중에 패킷을 수집하여 도청할 수 있다. 암호화로 도청을 피하는 방법 통신 암호화 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS라고 부른다. 콘텐츠 암호화 콘텐츠의 내용 자체를 암호화해 버리는 방법이다. 7.1.2 통신 상대를 확인하지 않..
6장 HTTP 헤더 6.1 HTTP 메시지 헤더 메시지 헤더: 클라이언트와 서버 처리에 필요한 주요 정보가 거의 다 여기에 있다. 메시지 바디: 사용자와 리소스를 필요로 하는 정보가 있다. HTTP 프로토콜의 리퀘스트와 리스폰스에는 반드시 메시지 헤더가 포함되어 있다. 메시지 헤더는 클라이언트나 서버가 리퀘스트나 리스폰스를 처리하기위한 정보가 들어있다. 리퀘스트의 HTTP 메시지 메소드, URI, HTTP 버전, HTTP 헤더 필드 등으로 구성되어 있다. 리스폰스의 HTTP 메시지 HTTP 메시지와 HTTP 버전, 상태 코드(코드와 설명), HTTP 헤더 필드 등으로 구성되어 있다. HTTP 요청에서 가장 다양한 정보를 가지고 있는 것이 HTTP 헤더 필드다. 6.2 HTTP 헤더 필드 6.2.1 HTT..
5장 HTTP와 연계하는 웹 서버 웹 서버는 1대의 서버에서 멀티 도메인으로 웹사이트를 실행하거나 중계 서버를 두어 통신 중에 효율을 올릴 수 있다. 5.1 1대로 멀티 도메인을 가능하게 하는 가상 호스트 HTTP/1.1에서는 하나의 HTTP 서버에 여러 개의 웹사이트를 실행할 수 있다. 고객마다 다른 도메인을 가지고, 다른 웹사이트를 실행할 수 있다, 이를 위해 가상 호스트라는 기능을 사용한다. HTTP Request를 보내는 경우에 호스트명과 도메인 명을 완전하게 포함한 URI를 지정하거나, 반드시 Host 헤더 필드에서 지정해야만 멀티 도메인을 적용할 수 있다. 5.2 통신을 중계하는 프로그램: 프록시, 게이트웨이, 터널 HTTP는 클라이언트와 서버 이외에도 프록시, 게이트웨이, 터널등으로 서버를 ..
조건부 로직 간소화 조건부 로직은 특별한 경우에 어떤 로직이 실행되는 것인데 도메인이 복잡해질수록 조건식도 복잡해질 수 밖에 없다. 복잡해진 조건식을 잘 다루지 못하면 코드를 읽는게 어렵고 버그가 발생할 확률이 높다. 그래서 잘 다뤄야 한다. 10.1 조건문 분해하기 if(!aDate.isBefore(plan.summerStart) && !aDate.isAfter(plan.summerEnd)) { charge = quantity * plan.summerRate; } else { charge = quantity * plan.summerRate + plan.regularServiceCharge; } if(summer()){ charge = summerCharge(); } else { charge = regu..
4장 결과를 전달하는 HTTP 상태 코드 클라이언트가 HTTP 리퀘스트를 보낸 결과, 즉 서버가 정상적으로 처리되었는지 아니면 에러가 발생했는지를 알려주는게 HTTP 상태 코드다. 4.1 상태 코드는 서버로부터 리퀘스트 결과를 전달한다. 클라이언트가 서버를 향해 리퀘스트를 보낼 때 서버에서 그 결과가 어떻게 되었는지 알려주는 것이 상태 코드의 역할이다. 정상적으로 처리했는지 에러였는지 알 수 있다. 200 OK와 같이 3자리 숫자와 설명으로 나타낸다. 1xx(Informational): 리퀘스트를 받아들여 처리중 2xx(Success): 리퀘스트를 정상적으로 처리했음 3xx(Redirection): 리퀘스트를 완료하기 위해서 추가 동작이 필요 4xx(Client Error): 서버는 리퀘스트 이해 불가능..
3장 HTTP 정보는 HTTP 메시지에 있다. HTTP 통신에는 클라이언트에서 서버로 보내는 리퀘스트와 서버에서 클라이언트로 보내는 리스폰스가 있다. 3.1 HTTP 메시지 HTTP에서 교환하는 정보를 HTTP 메시지라고 하고 리퀘스트측 메시지는 리퀘스트 메시지, 리스폰스측 메시지는 리스폰스 메시지라고 한다. HTTP 메시지는 복수행의 데이터로 구성된 텍스트 문자열이고 크게 구분하면 메시지 헤더와 메시지 바디로 구분되며 개행 문자(CR+LF)로 메시지 헤더와 메시지 바디를 구분한다. 메시지 바디가 항상 존재하는 것은 아님(GET, DELETE등) 메시지 헤더: 서버와 클라이언트가 꼭 처리해야 하는 리퀘스트와 리스폰스 내용과 속성등 메시지 바디: 꼭 전송되는 데이터 그 자체 3.2 리퀘스트 메시지와 리스폰..
Next.js 14 버전의 패치노트를 보면 Partial Prerendeing(PPR)이라는 것을 Preivew 단계로 소개하고 있습니다. 간단한 설명으로는 정적 리소스의 빠른 응답과 동적인 컨텐츠의 스트리밍이라고 표현하고 있는데 오묘한 느낌이라 제대로 이해하기 위해 해당 방식을 찾아보았습니다. 앞으로는 Partial Prerendering은 PPR이라고 표현하겠습니다. PPR이란? PPR은 하나의 페이지에서 static한 부분은 사용자에게 바로 보여주고, dynamic한 부분은 fallback을 보여주다가 컴포넌트의 준비가 끝나면 해당 컴포넌트를 보여주게 됩니다. 하나의 페이지에서 static, dynamic한 렌더링을 새로운 API를 학습할 필요 없이 더욱 빠르게 제공할 수 있게 해줍니다. PPR은 ..