본문 바로가기

전체 글

(28)
HTTP 2.0 HTTP 1.1 HTTP Pipelining HTTP 1.0은 기본적으로 Connection 당 하나의 요청을 처리할 수 있습니다. 그렇기 때문에 동시전송은 불가능하고 하나의 요청에 대한 응답이 온 후 다음 요청을 처리하게 됩니다. 위에서도 말했듯이 수 많은 멀티미디어 리소스들이 있는 상황에서 이러한 특징은 Network Latency를 발생시킵니다. 이를 위해 HTTP 1.1에서 HTTP Pipelining 이 도입되었습니다. 이는 TCP 안에 두 개 이상의 HTTP 요청을 담아 Network Latency을 줄이는 방식입니다. 하지만 이는 정확히 구현하기 힘들 뿐 아니라 HOL Blocking이 발생합니다. HOL Blocking HOL은 Head of Line의 줄임말로서 앞선 요청에 의해 뒤에 요..
HTTP 1.1 Connection 4장 커넥션 관리 목차 HTTP는 어떻게 TCP 커넥션을 사용하는가? TCP 커넥션의 지연, 병목, 막힘 병렬 커넥션, keep-alive 커넥션, 커넥션 파이프라인을 활용한 HTTP의 최적화 커넥션 관리를 위해 따라야 할 규칙들 TCP 커넥션 TCP 커넥션이 맺어지면 주고받는 데이터들은 손실, 손상되지 않고 순서대로 전달 우리가 아는 3-Way-Handshake는 바로 (4)에서 TCP 커넥션을 맺으며 수행 이 맺어진 커넥션을 통해 통신(Request와 Response)을 하게되고 통신이 완료된 후 커넥션은 close 이 때, 흔히 얘기하는 데이터는 IP 패킷, IP 데이터그램을 통해 전송 여기서 A, B, C가 각각 하나의 패킷이다. 하나의 큰 덩어리 데이터를 작은 패킷단위로 나누어 쪼개는 이유는 뭘..
HTTP 리다이렉션과 부하균형 리다이렉션과 부하균형 이 글은 HTTP 완벽가이드 20장을 참고해 정리한 포스팅입니다. 시작하기에 앞서 HTTP 메시지의 데이터는 네트워크 통신과정에서 많은 프로토콜에 의해 통제됩니다. HTTP가 고려하는 것은 오직 출발지(송신자)와 목적지(수신자) 뿐이지만, 미러링된 서버, 웹 프락시, 캐시 등 역시도 고려되어야 하므로 항상 단순하지만은 않습니다. 리다이렉션 기술은 HTTP 메시지의 최종 목적지를 정하는것과 관련되어있고, 보통 메시지가 프락시,캐시, 서버팜의 특정 웹서버 중 어디에서 끝나는지 판별하기 위해 사용한다고 합니다. 리다이렉션 기술은 클라이언트의 메시지를 명시적으로 요청하지 않은 곳으로 보낼 수 있습니다. 리다이렉션을 하는 이유 HTTP 애플리케이션은 언제나 아래 세가지를 원하기 때문에 리다이..
HTTP 쿠키 클라이언트 식별과 쿠키 웹 서버는 서로 다른 수천개의 클라이언트와 동시에 통신한다 서버 들은 익명의 클라이언트로 부터 받는 모든 요청을 처리하는 것 뿐만 아니라 서버와 통신하고 있는 클라이언트를 추적해야 할 수도 있다 개별 접촉 ● HTTP는 익명으로 사용하며 상태가 없고 요청과 응답으로 통신하는 프로토콜 ● 웹 서버는 요청을 보낸 사용자를 식별 하고 사용자의 요청을 추적하기 위해 약간의 정보를 이용한다 ex) 쇼핑몰이 사용자 맞춤 추천 , 불필요한 정보를 매번 입력하는것 방지 ● HTTP 트랜잭션은 상태가 없다 많은 웹사이트에서 사용자의 상태를 남겨 사용자와 사이트를 상호작용 시킨다 HTTP 헤더 ● From 헤더 From 헤더는 사용자의 이메일 주소를 포함한다 -> From 헤더로 사용자를 식별할 수..
웹 서버 웹 서버의 역할 리소스에 대한 HTTP 요청을 받아서 클라이언트에게 컨텐츠를 제공 HTTP 프로토콜 구현 웹 리소스 관리 웹 서버 관리 기능 TCP 커넥션에 관리에 대한 책임은 운영체제와 같이함. 웹 서버의 형태 다목적 소프트웨어 웹 서버 임베디드 웹서버 다목적 소프트웨어 웹 서버 웹서버를 컴퓨터 시스템에 설치하고 실행 넷크래프트가 발표한 웹 서버 시장 점유율 (2021년 7월) nginx: 36.54% 아파치 : 25.61% 마이크로소프트 : 4% 임베디드 웹 서버 소비자용 제품에 내장되는 웹 서버 진짜 웹 서버가 하는 일 커넥션 맺기 원치 않는 클라이언트의 커넥션 요청은 안받을 수 있음 HTTP 요청 받기 요청 처리하기 리소스에 접근하기 HTTP 응답 만들기 응답을 클라이언트에게 보내기 로그 파일에 ..
mobx가 불변성을 지키지 않아도 되는 이유(mobx 내부 코드 살펴보기) 리덕스만 사용하다가 최근에 mobx를 공부하는 일이 생겼다. 하나의 스토어만 사용해야 하는 리덕스와 다르게 mobx는 여러개의 store를 사용할 수 있었고 reactive 방식으로 동작하는 것이 매우 매력적이었다. 그 중에서 가장 이질감이 느껴졌던 부분은 상태 업데이트 중에 불변성을 지키지 않아도 된다는 것이다. 리덕스처럼 새로운 객체로 감쌀 필요 없이 상태를 매우 직관적으로 그냥 할당하면 된다. 매우 편리해서 좋았지만, 한편으론 궁금했다. 도대체 어떻게 이런 일이 가능할까? 그래서 mobx 내부 소스코드를 살짝 살펴봤다. 결론적으로 말하자면 mobx는 es6의 Proxy와 Reflect를 이용해 observable 객체의 변경을 감지하고 필요한 처리를 한다. es6의 Proxy와 Reflect를 알고..
리액트 프로젝트 배포를 리버스 프록시 구조로 개선하기 http 완벽 가이드 책을 공부하면서 http 2.0과 1.1의 차이를 학습했고 현재 제가 진행중인 최근 프로젝트에서 썸네일 같은 이미지들을 많이 다룰 일이 생겼고 슬슬 배포도 진행중인 상황이라 http 2.0이 많이 필요한 상황이었습니다. 스터디를 통해 알게된 것은 http 2.0은 https 위에서만 돌아간다는 것입니다. (브라우저 정책) 그래서 프로젝트에선 이미 웹서버와 let's encrypt를 이용해 인증서를 발급받고 https를 구축한 상태이기 때문에 문제가 없지 않을까 토론하던 중 문제를 발견하게 됩니다...! 바로 위 사이즈의 as-is 상태처럼 프론트 빌드 파일이 있는 웹서버하고는 https가 적용되지만 js가 브라우저에서 돌아가면서 api 서버와 직접적으로 통신하게 되는 구조여서 이 a..
CSS 여백을 컴포넌트로 관리하는 이유 주말마다 프론트 개발자 친구와 같이 클론코딩을 하고 있던 중 이해하기 어려운 코드를 보게 되었습니다. 이 사이트는 컴포넌트간 여백을 위 코드처럼 컴포넌트로 관리하는 것입니다. 굉장히 간단하지만 이유를 생각하기 어려웠습니다. 왜 저렇게 하는 걸까? 보통은 margin을 주든, padding을 주든지 할텐데 큰 이슈는 아니어서 그냥 저는 css로 margin을 주는 식으로 개발을 진행했습니다. 그러던 중에 다른 페이지에서 이전에 활용한 컴포넌트를 재사용하는 일이 있었는데 이전에 사용했던 여백이 컴포넌트 코드에 포함되어 있어서 여백을 수정해야 하는 상황이 발생했습니다. 그래서 제가 했던 방법은 여백을 props로 margin을 조정하여 주게끔 구현하고 있었는데 문뜩 위 코드가 떠오른 겁니다. 여백 자체를 컴포..