일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 자바스크립트
- HTTP 완벽 가이드
- 크롤링
- 타입스크립트
- 소켓
- typescript
- 가천대
- 프로그래머스
- Crawling
- Algorithm
- Node.js
- 수학
- socket
- ip
- Nestjs
- dp
- type challenge
- 프로그래머스 레벨 2
- 그래프
- 백준
- dfs
- 쉬운 문제
- BFS
- TCP
- HTTP
- javascript
- 타입 챌린지
- 문자열
- 알고리즘
- 레벨 1
- Today
- Total
목록프로그래밍/HTTP (26)
kakasoo
PUT VS PATCH PUT은 멱등하고, PATCH는 비(非)멱등한 메서드라고 말한다. 여기서 멱등하다는 것은 여러 번 요청해도 결과가 동일하다는 것이고, 비멱등하다는 것은 여러 번 요청하면 그 결과가 누적되서 나온다, 즉 동일하지 않다는 것을 의미한다. 예컨대 GET으로 조회하는 것은 멱등하다. 새로고침을 여러 번 한다고 해서 페이지가 바뀌는 경우는 없다. DELETE도 멱등하다. 처음에 삭제를 하고, 두번째에서는 삭제할 게 없어서 삭제된 것처럼 표시된다. 세번째 네번째도 역시 삭제할 게 없으니 아무것도 바뀔 게 없다. 하지만 PUT, PATCH와 같이 수정을 위한 메서드는 어떨가? 이 멱등, 비멱등에 대한 구분은 결국 서버 측에서 API를 만드는 개발자가 구현해야 한다. 그렇다면 수정에 대한 멱등과..
HTTP 완벽 가이드 3장, HTTP 메시지 안전한 메서드 9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD ..
콘텐츠 리소스를 저장, 중개, 관리하는 일을 통틀어 웹 호스팅이라고 한다. 호스팅은 웹 서버의 가장 중요한 기능으로, 콘텐츠를 저장해서 제공하고 관련 로그에 접근하거나 관리하는 데에는 모두 서버가 필요하다. 하드웨어나 소프트웨어를 직접 관리하기 어렵다면 호스팅 서비스나 호스팅 업체가 필요할 것이다. 18.1 호스팅 서비스 각 개인이 자체 컴퓨터 하드웨어를 구매하고 망을 구축하는 비용이 크기 때문에, 전문적으로 호스팅만 해주는 사업이 생겨났다. 18.1.1 간단한 예 : 전용 호스팅 ( 생략 ) 18.2 가상 호스팅 대부분의 시간동안 놀고 있을 사이트를 위해 전용 웹 서버를 가지는 것은 낭비기 때문에, 많은 웹 호스팅 업자는 컴퓨터 한 대를 여러 고객이 공유하게 해서 저렴한 호스팅 서비스를 제공한다. 이를..
예를 들어 우리 사이트의 주 고객이 영어 사용자와 프랑스어 사용자 양측이 존재한다면, 우리는 사용자에 맞게 콘텐츠를 제공해줘야 한다. HTTP는 이런 판단이 가능하게 내용협상이란 방법을 제공한다. 이 방법은 하나의 URL이 여러 가지 리소스 중 적합한 것을 제공하도록 할 수 있다. 여기서는 서로 다른 버전을 배리언트( Variant ) 라고 부른다. 17.1 내용 협상 기법 서버가 클라이언트에게 맞는 리소스인지 판단하는 세 가지 방법이 있다. 다음 단에서 클라이언트 주도 기법과 서버 주도 기법에 대해 자세히 설명하고, 여기에는 투명 하나를 간략히 설명한다. 투명 주로 프락시 캐시와 같이 투명한 중간 장치를 거쳐 대신 협상한다. 속도는 위 두 가지의 중간 쯤 되지만, 투명 협상의 경우 어떻게 하는지에 대한..
HTTP는 여러 언어와 문자로 된 국제 문서들의 처리 및 전송을 지원해야 한다. 16.1 국제적인 콘텐츠를 다루기 위한 HTTP 지원 엔터티 본문은 그저 비트일 뿐이다. 이 비트들을 어떻게 해석할 것인지를 서버와 클라이언트가 의사소통해야 한다. 서버는 클라이언트에게 HTTP Content-Type charset 매개변수와 Content-Language 헤더를 통해서 알려준다. 클라이언트는 서버에게 Accept-Charset과 Accept-Language 헤더를 보내서 자신이 해석 가능한 언어를 말한다. Charset은 iso 인코딩을 말하는 것이고, Language는 인간의 언어를 의미하는데, 콜론으로 구분하여 q=0.8과 같이 선호도를 표현할 수 있다. 16.2 문자집합과 HTTP 16.2.1 차셋(C..
HTTP는 다음을 보장한다. 객체는 올바르게 식별된다. ( Content-Type, Content-Language 등 헤더를 이용한다. ) 객체는 올바르게 압축이 풀린다. ( Content-Length, Content-Encoding 등 헤더를 이용한다. ) 객체는 항상 최신이다. ( 엔터티 검사, 캐시 만료 제어 ) 사용자의 요구를 만족한다. ( 내용 협상을 위한 Accept 관련 헤더를 이용한다. ) 네트워크 사이를 빠르고 효율적으로 이동한다. 조작되지 않고 온전하게 ( 안전하게 ) 도착할 것이다. 15.1 메시지는 컨테이너, 엔터티는 화물 HTTP를 컨테이너라고 한다면 HTTP 엔터티는 메시지의 실질적인 화물이다. 엔터티는 엔터티 헤더와 엔터티 본문으로 나뉜다. HTTP/1.1의 10가지 주요 엔터..
14.1 HTTP를 안전하게 만들기 HTTP 보안 버전은 효율적이고 이식성이 좋아야 하고 관리가 쉬워야 하며 현실 세계의 변화에 대한 적응력이 좋아야 한다. ⇒ 이를 위해서 아래의 것이 필요하다. 서버 인증 : 클라이언트가 상대 서버가 진짜임을 인식할 수 있어야 한다. 클라이언트 인증 : 서버가 상대 클라이언트가 진짜임을 인식할 수 있어야 한다. 무결성 : 클라이언트와 서버는 그들의 데이터가 위조되는 것으로부터 안전해야 한다. 암호화 : 클라이언트와 서버는 도청에 대한 걱정 없이 서로 대화할 수 있어야 한다. ( SSL ) 효율 : 저렴한 클라이언트나 서버도 이용할 수 있도록 알고리즘은 충분히 빨라야 한다. 편재성 : 프로토콜은 거의 모든 클라이언트와 서버에서 지원되어야 한다. 관리상 확장성 : 누구든 ..
12.1 인증 인증은 당신이 누구인지 증명하는 것이다. 완벽한 인증은 없다. 다만 인증을 통해 당신이 누군지 판단하는 도움은 될 수 있다. 12.1.1 HTTP의 인증요구/응답 프레임워크 HTTP는 사용자 인증을 하는 데 사용하는 자체 인증요구/응답 프레임워크를 제공한다. 순서는 요청, 인증요구, 인가, 성공의 단계로 이루어진다. 맨 처음 요청은, 클라이언트가 서버 측에 정보를 요청한다는 의미이다. 이 때에는 아무런 헤더도 필요없고, 그저 GET 메서드를 했다는 의미이다. 다음부터가 인증 요구이다. 인증 요구는 서버가 사용자에게 사용자 이름과 비밀번호를 제공하라는 지시다. 이 때, 401 Unauthorized 상태 정보와 함께 요청을 반려한다. 이 때 WWW-Authenticate 헤더에 각 영역에 대..
웹 서버는 서로 다른 수천 개의 클라이언트와 동시에 통신한다. 서버는 모든 요청을 처리할 뿐만 아니라, 특정 클라이언트를 추적해야 할 수도 있다. 이 장은 서버가 통신 대상을 식별하는 기술에 대해 설명한다. 11.1 개별 접촉 HTTP는 익명으로 사용한다. 또한 연결에 대한 정보를 가지지 않으며 매 요청이 일회성에 독립적이다. 즉 무상태성을 지닌다. 다만 웹 서버는, 이런 HTTP 속에서도 약간의 정보를 이용할 수가 있다. 현대의 웹 사이트들은 개인화된 서비스를 제공하고 싶어 한다. 네트워크로 연결된 사용자에 대해 더 많은 것을 알고 싶어하고 사용자의 정보를 저장해두려고 한다. 개별 인사 개개인에게 맞춰져 있는 것 같은 느낌을 주기 위해 사용자에게 특화된 환영 메시지나 페이지를 만든다. 사용자 맞춤 추천..
7.7 캐시 처리 단계 HTTP GET 메시지를 하나 보내면 캐시 처리는 일곱 가지 절차에 따라 이루어진다. 요청 받기 : 캐시는 요청 메시지를 읽는다. 파싱 : 캐시는 메시지를 파싱하여 URL과 헤더들을 추출한다. 검색 : 캐시는 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아온다. 신선도 검사 : 캐시된 사본을 찾았다면 최신의 것이 맞는지 검사한다. 아니라면 서버로부터 변경사항을 확인한다. 응답 생성 : 응답을 생성한다. 발송 : 클라이언트에게 응답을 돌려준다. 로깅 : 선택적으로 로그 파일에 트랜잭션을 서술한 로그를 남긴다. 7.7.1 단계 1 : 요청 받기 캐시는 네트워크 커넥션에서의 활동을 감지, 데이터를 읽는다. 고성능 캐시는 동시에 여러 커넥션으로부터 데이터를 읽고 메시지 전체가 ..
웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치다. 웹 요청이 캐시에 도착했을 때, 사본이 존재한다면 서버에 갈 필요없이 즉시 반환한다.네트워크 요금으로 인한 비용을 줄여준다.네트워크 병목을 줄여준다.원 서버에 대한 요청을 줄인다, 즉 부하를 줄여서 전체 속도를 빠르게 해준다.거리로 인한 지연을 줄여준다.이 장에서는 캐시가 어떻게 성능을 개선, 비용을 절감하는지, 그리고 그것을 어떻게 측정하는지, 캐시가 있을 가장 적절한 위치는 어디인지에 대해 말할 것이다.또한 HTTP가 어떻게 캐시된 사본을 신선하게 유지하는지, 캐시와 서버와의 상호작용은 어떻게 이뤄지는지를 이야기한다.7.1 불필요한 데이터 전송복수의 클라이언트가 똑같은 문서를 위해 서버에 접근할 때, 서버는 각각 한 번씩 클라이..
웹 프락시 서버는 중개자다. 클라이언트와 서버 사이에서 중개하는 역할을 한다. 이 장에서는 프락시 기능과 동작을 포함한, HTTP 프락시의 모든 것을 배운다. HTTP 프락시와 웹 게이트웨이의 비교 프락시의 활용법 프락시의 실제 네트워크에서의 배치와 트래픽이 프락시 서버로 가는 과정 브라우저에서의 프락시 설정 HTTP 프락시 요청과 서버 요청의 차이, 프락시가 브라우저 동작을 바꾸는 과정 프락시 서버들을 통과하는 메시지의 경로를 Via 헤더와 TRACE 메서드를 통해 기록하는 법 프락시에 기반한 HTTP 접근 제어 프락시가 클라이언트와 서버 사이에서 다른 기능과 버전들을 지원하는 원리 6.1 웹 중개자 프락시는 클라이언트 사이에서 서버와의 트랜잭션을 중개하는 역할을 한다. 프락시가 없으면 클라이언트는 서..