목록CS/네트워크 (7)
빙응의 공부 블로그

📝캐시 캐시가 없으면 해당 페이지 새로고침마다 이미지 등을 다운받아야 한다. 이것은 매우 비효율적인 행위로 캐시는 자신의 브라우저에 저장되어 다운로드를 안하고 사용할 수 있다. 캐시는 유효 시간을 가지고 있으며, 유효 시간 만료 후의 특별한 로직을 가지고 있다. Last-Modified + if-modified-since 캐시 유효 시간이 초과해서 서버에 다시 요청하면 데이터가 변경이 안되어도 다시 다운받아야 한다. 이것을 해결하기 위한 방법이 Last-Modified + if-modified-since (검증헤더 + 조건부요청)이다. 밑은 코드는 캐시 생성 과정이다. 해당 코드에서 60초 후 캐시가 만료되었을 때 요청을 다시보내면 서버에서 데이터 수정일을 비교하여 수정되지 않았다면 클라이언트는 다시 캐..

📝HTTP 헤더 HTTP 헤더는 요청/응답의 HTTP 전송 부가 정보를 저장하는 필드이다. 과거의 헤더 분류 RFC2616 General 헤더 : 메시지 전체에 적용되는 정보 Request 헤더 : 요청 정보 Response 헤더 : 응답 정보 Entitiy 헤더 : 엔티티 바디 정보 (엔티티 타입, 길이) 현재의 헤더 분류 RFC723X 엔티티 -> 표현 메시지 본문을 페이로드라고 부른다. 표현은 요청이나 응답에서 전달할 실제 데이터이다. 표현 헤더 전송, 응답 둘다 사용 Content-Type : 표현 데이터의 형식 Content-Encoding : 표현 데이터의 압축 방식 Content-Langage : 표현 데이터의 자연 언어 Content-Length : 표현 데이터의 길이 협상(콘텐츠 네고시에..

📝상태 코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능이다. 100번대 : 요청이 수신되어 처리중 200번대: 요청 정상처리 300번대 : 리다이렉트 400번대 : 클라이언트 오류, 잘못된 문법등으로 서버에서 수행불가 500번대: 서버 오류, 서버 내부 문제 📝 200번대 - 성공 클라이언트의 요청을 성공적으로 처리한 것이다. 200 OK - 요청 성공 201 Created - 요청 성공해서 새로운 리소스가 생성됨 202 Accepted - 요청이 접수되었으나 처리가 완료되지 않았음 204 No Content - 서버가 요청을 성공적으로 수행했지만, 응답 값을 본문에 보낼 데이터가 없음 예) 웹 문서 편집기 save 버튼 결과로 아무 내용이 없어도 되기 때문 204 메시지로 성공을 인식..

📝HTTP API 만들어보기 회원 정보 관리 API를 만들어보자 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 이런 기능을 만들건데 과거의 나는 어떻게 했을까? 물론 나는 타임리프 매핑으로 해서 좀 다를 수 있으나 문제가 많다.. @GetMapping("/addMember") @PostMapping("/member/idValidation") @PostMapping("/member/nameValidation") 이거처럼 지멋대로 하였다. 크아아악!!!! URI 리소스 식별 설계법 리소스의 의미를 담아야한다. 회원의 리소스는 member 개념 자체가 리소스이다. 리소스를 어떻게 식별해야하는가? 회원 등록, 수정, 조회에 대한 것을 모두 제외하고 리소스만 매핑하여 따로 처리한다. 회원 목록 조회 ..

📝HTTP - HyperText Transfer Protocol 모든 것이 HTTP HTTP는 인터넷에서 데이터를 주고 받기 위한 프로토콜 중 하나이다. 현재의 HTTP는 모든 것을 전송한다. HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML(API) 거의 모든 형태의 데이터를 전송한다. 역사 HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더X HTTP/1.0 1996년 : 메서드, 헤더 추가 HTTP/1.1 1997년 : 가장 많이 사용 HTTP/2 2015년 : 성능 개선 HTTP/3 진행중 : TCP 대신에 UDP로 커스텀 성능 개선 기반 프로토콜 TCP : HTTP/1.1, HTTP/2 UDP : HTTP/3 이유 TCP는 3 way때문에 속도에 대한 한계가 ..

📝URI(Uniform Resource Identifier) URI는 소스를 식별하고 위치를 지정하기 위한 문자열의 구성이며, 웹에서 가장 흔히 볼 수 있는 형태이다. 구성은 다음과 같다. URL : Resource Locator 리소스가 있는 위치를 지정 URN : Resource Name 리소스의 이름을 부여 위치는 변할 수 있지만, 이름은 변하지 않는다. 그러나 이름만으로 실제 리소스를 찾는 방법은 매우 불편하여 사용하지 않는다. URL만 알면 문제 없다. URL의 구성 scheme://[userinfo@]host[:port][/path][?query][#fragment] 하나하나씩 살펴보자 Scheme 주로 프로토콜을 사용한다. http, https, ftp 등등 http는 80 포트, https..