Brute force Study

HTTP 기본(비 연결성, HTTP 메시지)연결을 유지하는 모델    클라이언트 1, 2, 3의 연결이 유지되고 있다단점 : 클라이언트가 요청을 보내지 않아도 계속 연결을 서버가 유지해야 한다연결을 유지하지 않는 모델  요청을 주고 받을 때만 연결을 하고 그 다음에는 연결을 끊어버려 서버가 유지하는 자원을 최소한으로 줄일 수 있다비 연결성(connectionless)HTTP는 기본이 연결을 유지하지 않는 모델일반적으로 초 단위의 이하의 빠른 속도로 응답1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.서버 자원을 매우 효율적으로 사용할 수 있음비 연결성의 한계와 극복TCP/IP 연결을 새로 ..

HTTP 기본(클라이언트 서버 구조, Stateful, Stateless)Hyper Text Transfer ProtocolHTTP 메시지에 모든 것을 전송HTML, TEXTIMAGE, 음성, 영상, 파일JSON, XML (API)거의 모든 형태의 데이터 전송 가능서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용지금은 HTTP 시대!HTTP 역사HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더XHTTP/1.0 1996년: 메서드, 헤더 추가HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)HTTP/2 2015년: 성능 개선HTTP/3 진행중: TCP 대신에 UDP ..

URI와 웹 브라우저 요청 흐름URI(Uniform Resource Identifier)리소스를 식별하는 통합된 방법.Uniform : 리소스 식별하는 통일된 방식Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음)Identifier : 다른 항목과 구분하는데 필요한 정보URI? URL? URN?URI는 로케이터(locater), 이름(name) 또는 둘 다 추가로 분류될 수 있다URL : Uniform Resource Locater, 리소스가 있는 위치를 지정우리가 웹 브라우저에 적는 것URN : Uniform Resource Name, 리소스에 이름을 부여ex) ISBNurn:isbn:12345678 (어떤 책의 isbn URN)URN 이름만으로 실제 리소스를 찾을 수 있는 방법이..

File OrganizationFrom MySQL to InnoDBFunction callsFrom InnoDB to LinuxSystem callFrom Linux to File SystemExt4_file_Write_iterFrom File System to HDDSATA_commands 데이터베이스는 파일의 모음으로 저장됨 각 파일은 records의 sequence각 파일은 하나 이상의 페이지로 구성됨각 페이지는 하나 이상의 레코드를 포함함레코드는 필드의 시퀀스하나의 접근 방법레코드 크기가 고정되어 있다고 가정각 파일은 하나의 특정 유형의 레코드만 포함서로 다른 Relation을 위해 서로 다른 파일 사용레코드는 디스크 블록보다 작다고 가정한다.Fixed-Length Records간단한 접근 방법각..

데이터베이스는 본질적으로 data storage system입니다  물리적 저장 매체의 분류Volatile storage: 전원이 꺼지면 내용이 손실됨non-safeex) memoryNon-volatile storage:전원이 꺼져도 내용이 지속됨2차 및 3차 storage 포함, 배터리 백업된 main-memory 포함저장 매체 선택에 영향을 미치는 요소:데이터 접근 속도데이터 단위당 비용reliability(신뢰성)Storage HierarchyPrimary storage: 가장 빠른 매체지만 volatile (cache, main memory)Secondary storage: 다음 계층, non-volatile, 적당히 빠른 접근 시간on-line storage라고도 함예: flash memory,..

Design Phases(디자인 단계)초기 단계잠재적 database 사용자들의 data 요구를 완전히 파악두 번째 단계data model 선택선택한 data model의 개념 적용이러한 요구사항을 database의 개념적 schema로 변환완전히 개발된 개념적 schema는 기업의 기능적 요구사항(functional requirements)을 나타냅니다.data에 대해 수행될 작업(또는 트랜잭션)의 종류를 설명최종 단계abstract data model에서 database 구현으로 이동논리적 설계(Logical design)database schema 결정database 설계는 '좋은' relation schemas 컬렉션을 찾아야 함을 요구합니다.비즈니스 관점에서 decision: database에 ..