계층화된 프로토콜의 역할

(표 1)은 OSI 참조 모델을 정리한 것이다. 여기서 가장 아래 부분인 물리 계층부터 각각의 계층마다 고유의 작업들이 정의돼 있다.
또한 각 계층은 반드시 자신의 영역에서 운영되는 하위 계층을 통해 서비스를 받고, 상위 계층으로 서비스를 제공하도록 규정돼 있다. 예를 들면 3계층의 네트워크 계층은 2계층인 데이터링크 계층을 통해 서비스를 받고, 상위 계층인 전송 계층에 작업한 내용을 서비스하는 식이다.
한편 각 계층은 전송 데이터에 각 계층에서의 요구 조건과 처리 정보를 포함한 헤더라는 고유의 제어 정보를 전달 메시지에 추가해 다음 계층으로 보내며, 수신측의 동일 계층에 의해 해석돼 처리된다. 예를 들면 송신측 컴퓨터의 5계층에서 추가된 헤더는 수신측 컴퓨터의 5계층에서 해석되며, 해석된 헤더는 지정된 작업을 수행한 다음 제거된 상태로 다음 계층으로 넘어가, 최종적으로 수신측 컴퓨터에는 데이터만 전송된다.
이때 각 계층 간에 전달되는 데이터의 단위는 계층에 따라 서로 다른 이름으로 불리며, 이를 ‘서비스 데이터 단위’라고 한다.
프로토콜이 데이터를 전송하기 위해 사용하는 기본 단위를 PDU(Protocol Data Unit)라고 한다. 즉, 물건을 운반할 때 상자 단위로 포장해 운반하는 것과 같이 프로토콜은 정보의 운반을 위해 PDU라는 상자를 이용하는 것이다.
상자 단위로 물건을 포장해서 운반할 때 상자마다 물품의 내용이나 발송처, 수신처 등을 표기하는 것과 마찬가지로 PDU에도 사용자 정보뿐만 아니라 데이터의 발신처와 수신처에 대한 주소 정보와 전송 중에 에러가 발생했는지 확인하기 위한 패리티, 그밖에 흐름 제어 등을 위한 각종 정보가 함께 들어간다.
계층화된 프로토콜에서는 계층마다 PDU 이름을 독특하게 붙여 사용하는 경우가 있다(표 2). 2계층 PDU는 프레임(Frame), 3계층 PDU는 패킷(Packet), 4계층 PDU는 세그먼트(Segment) 등으로 부르는 것이 일반적이다. 그리고 특별한 이름이 없는 경우에는 그냥 몇 계층의 PDU라고 부른다. 특히 세그먼트라고 불리는 4계층 PDU는 TCP에서 사용하는 경우가 많다.

 

 TCP/IP와 OSI 참조 모델
일반적으로 가장 많이 사용되는 TCP/IP를 통해 OSI 참조 모델과 프로토콜에 대해 알아보자.
TCP/IP는 좁은 의미로는 1969년 미국방부가 제시한 ARPNET (Advanced Research Projects Agency NETwork)에서 제안한 프로토콜의 집합 중 인터네트워킹에 대한 핵심적 기능을 제공하는 TCP와 IP만을 지칭한다. 하지만 OSI의 3계층에서 7계층까지 해당 소프트웨어나 서비스 관련 프로토콜을 통틀어 얘기할 때도 사용한다.
TCP/IP는 3계층 프로토콜인 IP와 4계층 프로토콜인 TCP가 합쳐진 용어다(그림 2). 네트워크 계층에 해당하는 IP는 네트워크 환경에 흩어져있는 여러 노드 중에서 지정된 목적지를 찾아가는 경로를 설정하는 작업을 수행하고, TCP는 안정된 데이터 전송을 위해 흐름과 오류를 제어하는 역할을 맡는다.
TCP 외에 또 다른 4계층 프로토콜 중 하나인 UDP(User Datagram Protocol)는 TCP와는 달리 데이터의 신뢰성있는 전송을 보장하지는 않는다. 그러나 신뢰성이 매우 높은 회선을 사용하거나 데이터의 확실한 전송을 요하지 않는 통신, 또는 한번에 많은 상대에게 메시지를 전송할 경우에는 보다 효율적이다.
일반적인 고속 이더넷 환경에서 FTP를 통해 서버에 접속하는 경우를 OSI 참조 모델을 통해 생각해 보자. 우선 클라이언트의 FTP 클라이언트는 애플리케이션 계층의 프로토콜인 FTP 규격에 맞춰 데이터에 헤더를 붙여 하위 계층으로 전송하고, 4계층 TCP 프로토콜이 수신측 서버의 4계층과 통신을 통해 데이터의 정합성을 테스트하고 오류가 있을 경우 재전송을 하는 등의 일을 처리한다. 또한 3계층에서는 IP 어드레스를 통해 송신측이 특정 수신측을 지정하고 경로를 설정한다.
그 아래의 2계층과 1계층에서는 두 노드 사이의 물리적인 연결과 디지털 데이터를 전기적인 신호로 변환해 전송하고 신호가 약할 경우에는 증폭하는 등의 일을 처리한다.

 

 OSI 참조모델의 계층별 이해

 물리 계층
OSI 7계층 참조 모델의 1계층은 물리 계층이다. 이 계층에서 담당하는 것은 네트워크 케이블과 신호에 대한 것으로, 물리적 신호(bit)의 전송 규칙을 조정하는 역할을 한다.
물리 계층은 전송 매체에 대한 규정은 정하지 않지만, 이를 구현하는 방법적인 면에서는 전송 매체와 깊은 관계를 맺고 있다. 참고로 물리 계층과 관련된 네트워크 연결 장비들은 다음과 같다.

 - 허브나 리피터 등의 전기적 신호를 재발생시키는 장비
- 각종 커넥터와 같은 전송 매체 연결 소자 등의 기계적인 연결 장치
- MODEM, CODEC 등 디지털/아날로그 신호 변환기

 

기본적으로 네트워크는 일대일 또는 멀티 포인트 방식으로 연결된다. 잘 알고 있듯이 일대일 방식은 두 통신 장비들이 직접 연결된 상태를 말한다. 이런 식으로 연결하면 회선을 전용으로 사용할 수 있으므로, 장비간 정해진 전송 용량과 대역폭을 보장받을 수 있다. 한편 멀티 포인트 연결은 3대 이상의 장비를 연결하는 방식을 말한다. 이 방식은 같은 주파수대를 공유하며, 전송 매체에 연결된 모든 장비가 전체 기능을 공유할 수 있다. 일반적으로 대규모 네트워크를 구축할 경우에는 일대일 연결과 다중점 방식을 적절히 혼합하는 방식으로 설계한다.
이 같이 다양하게 연결된 네트워크의 형태를 토폴로지라고 부른다. 즉, 어떤 형태나 구조로 연결된 것을 네트워크 토폴로지(Network Topology)라고 이해하면 된다. 단, 눈으로 보이는 물리적인 토폴로지 형태가 논리적으로는 동일하지 않을 수도 있다. 일반적인 토폴로지에는버스형(Bus), 링형(Ring), 스타형(Star), 메시형(Mesh), 셀룰러형(Cellular) 등이 있다.
1계층에서는 이외에도 전기적인 펄스나 광학적인 방법 또는 전자기적 파동을 통해 신호를 전달하는 방법에 대한 정의도 수행하며, 동기화 방식, 대역폭 등에 대한 개념을 정의한다.

 데이터 링크 계층
OSI 참조 모델의 두 번째 계층인 데이터링크 계층은 데이터 패킷을 생성하고 전송하는 방법을 규정하는 프로토콜에 대한 계층이다. 이 계층이 하는 일은 물리 계층에서 넘어오는 데이터의 오류를 검사하고 복구 기능을 담당할 뿐 아니라, 시스템 간 전송 속도 차에 의한 오류나 흐름 제어까지 도맡아 처리한다. 쉽게 얘기하자면 화물을 트럭에 싣고, 각 트럭을 고속도로로 보내며 화물이 무사히 목적지에 도착하도록 관리하는 역할을 담당한다.
다른 모든 계층과 마찬가지로 데이터링크 계층 또한 고유의 식별 정보를 전송 데이터 앞에 붙이고 있다. 이 정보에는 수신자와 송신자(물리적 또는 하드웨어적인)의 어드레스와 프레임 길이, 그리고 상위 계층의 정보가 포함돼 있다. 이 계층에 속하는 네트워크 연결 장비로는 브리지, 지능형 허브 등을 들 수 있다.
데이터 링크 계층의 여러 기능은 대개 MAC(Media Access Control)과 LLC(Logical Link Control)의 두 가지 계층으로 다시 세분화할 수 있다. MAC 계층은 동일 채널을 공유하는 통신 방법을 제어하기 위한 것이고, LLC 계층은 데이터 전송을 위해 각 장비들을 논리적으로 연결하고, 연결을 유지하는 역할을 담당한다.

 

네트워크 계층
네트워크 계층은 여러 개의 독립적인 네트워크 사이에서 데이터 전송에 관한 계층이다. 앞서 설명한 데이터링크 계층의 데이터 전송은 물리적인 장치의 어드레스 지정을 통해 단일 네트워크로 연결된 모든 장치에 데이터를 브로드캐스팅하며, 수신측 장비에서 확인해 자신에게 오는 데이터를 수신받는 방식이다.
그러나 네트워크 계층에서는 네트워크와 네트워크를 연결하는 인터네트워킹 환경에서 특정 경로를 선택해 권한이 없는 네트워크에 데이터를 전송하는 것을 미연에 방지할 수 있다. 또한 서로 다른 네트워크로 구성된 인터네트워킹을 통해 올바른 데이터 경로를 보장할 수도 있다. 네트워크 계층에서는 기본적으로 다음과 같은 사항을 수행한다

- 논리적으로 분리된 모든 네트워크에 고유한 네트워크 어드레스를 부여한다.
- 인터네트워크를 통해 컴퓨터와 라우터가 최적의 데이터 경로를 결정하도록 라우팅을 구현한다.
- 네트워크는 인터네트워크 내에서 예상되는 오류의 개수에 따라 서로 다른 단계의 연결 서비스를 구현한다.

 전송 계층
전송 계층은 복잡한 하위 계층 구조를 상위 계층이 알 필요가 없도록 감추기 위한 계층이다. 여기서는 상위 계층의 메시지를 세그먼트화한 후, 이 세그먼트를 세션 계층이나 상위 계층 프로세스에게 신뢰성 있게 전달하는 역할을 한다. 전송 계층은 하위 계층에서의 신뢰성이 모자라는 연결 서비스나 연결 지향 연결 서비스가 갖는 미비점을 해소하기 위한 역할을 수행한다. 여기서 신뢰성이 보장된다는 말은 데이터가 항상 전달된다는 것을 의미하지는 않는다.
예를 들어 케이블이 끊어졌을 경우에는 데이터의 전달을 보장할 수 없다. 만일 어떤 데이터가 수신측 장치에게 올바르게 전달되지 않은 경우, 전송 계층은 재전송을 개시하거나 상위 계층에게 이 사실을 통보할 수 있으며, 이에 근거해 상위 계층에서는 필요한 조치를 취하거나 사용자에게 옵션을 제공하게 된다.

 세션 계층
세션 계층은 상위 계층에서 필요로 하는 서버 이름과 어드레스를 하위 계층에서 제공되는 논리 어드레스 정보를 사용해 식별할 뿐 아니라, 서비스 제공자와 요청자 간을 연결하고 대화를 개시하는 역할을 담당한다. 이 기능을 수행하는 경우 세션 계층은 각 네트워크 구성 요소를 소개하거나 식별해내며 액세스 권한을 조정하기도 한다.

 프리젠테이션 계층
프리젠테이션 계층은 변환과 암호화를 통해 데이터를 주고받는 서로 다른 환경의 컴퓨터와 애플리케이션이 데이터를 이해할 수 있도록 돕는 기능을 수행한다.

 애플리케이션 계층
사용자로부터 데이터를 받아 하위 계층으로 전달하고, 하위 계층에서 전달하는 데이터를 사용자에게 전달하는 애플리케이션 계층은 여러 가지 실제적인 네트워크 서비스를 제공하는 계층이다.
애플리케이션 계층에는 각각의 네트워크 서비스에 대한 특정한 주제와 기능이 포함된다. 다시 말해, 이 계층 하부에 있는 여섯 계층이 일반적으로 네트워크 서비스를 지원하는 기술과 작업을 포함하는데 반해, 애플리케이션 계층에서는 특정 네트워크 서비스 기능을 수행하는데 필요한 프로토콜을 지원한다.
애플리케이션 계층 프로토콜이 지원하는 서비스로는 네트워크 서비스에 해당하는 파일, 프린트, 메시지, 애플리케이션, 데이터베이스 서비스 등이 포함된다.
OSI 7계층을 만든 이유는 프로토콜을 체계적으로 연구하기 위한 목적 외에도, 공용으로 사용할 수 있는 공개된 프로토콜을 만들기 위한 것도 있었다. 그러나 7계층이 발표된 시점에 이미 많은 프로토콜이 사용되고 있었고, 특히 WAN에서는 TCP/IP가 표준으로 자리잡아 독보적인 위치를 확보하고 있었다.
그 이후, 1계층과 2계층에서는 이더넷, 3계층과 4계층에서는 TCP/IP, NetBEUI, IPX 등이 업계 표준으로 자리잡았다.
한편 5, 6, 7계층은 각각이 별도로 구현되기보다는 통합된 형태의 서비스라는 이름으로 제공된다. 텔넷, FTP, 전자우편(SMTP, POP), HTTP, 뉴스그룹(NNTP), NetBIOS 등이 이와 같은 서비스에 해당한다.

출처 SERI.ORG

Posted by 달팽이맛나
,







지속성 쿠키와 세션 쿠키 비교

Internet Explorer 6의 쿠키 처리 방법을 이해하려면 지속성 쿠키와 세션 쿠키의 차이점을 아는 것이 좋습


니다. 지속성 쿠키는 정의된 만료 시간에 도달할 경우 삭제됩니다. 반면, 지정된 만료 시간이 없는 세션


쿠키는 Internet Explorer를 닫을 때 삭제됩니다.


제1 컨텍스트와 제3 컨텍스트

Internet Explorer 6은 제1 컨텐트를 호스트 도메인과 연관된 것으로 정의합니다. 제3 컨텐트는 호스트


도메인 이외의 도메인에서 만들어집니다. 예를 들어, 주소 표시줄에 www.wideworldimporters.com


입력하여 이동 했더니 이 사이트에 www.wingtiptoys.com의 배너 광고가 떠있다고 가정해 보십시오.


이 두 사이트에 쿠키를 설정할 경우, www.wideworldimporters.com의 쿠키가 제1 컨텍스트 쿠키이고

 
www.wingtiptoys.com의 쿠키가 제3 컨텍스트 쿠키가 됩니다.


이따금 상업용 웹 페이지에는 제1 컨텐트와 제3 컨텐트가 혼재해 있습니다. Internet Explorer 6 개인


정보 기능은 제1 컨텐트와 제3 컨텐트를 구별합니다. 이 때 근간이 되는 가정은 사용자의 제1 및 제3과의
 

관계가 서로 다르다는 것입니다. 실제로 사용자는 제3을 알지 못할 수도 있고 제3과 새로운 관계를 설정


할 것인지 선택할 수도 있습니다.


이러한 이유 때문에 제3 컨텐트에 대한 기본 개인 정보 설정은 제1에 대한 설정보다 엄격합니다.


참고) www.wideworldimporters.com 및 toys.wideworldimporters.com은 둘 다 deworldimporters.com

이라는 동일한 최소 도메인을 갖고 있습니다. 동일한 최소 도메인을 호스트 도메인으로 공유하는 컨텐트


를 제1 컨텐트로 간주하며, 마찬가지로 이러한 도메인에서 설정된 쿠키는 제1 쿠키로 간주합니다. 최소


도메인은 동일한 최상위 도메인(TLD)을 가져야 합니다. .com, .net, .org 등을 일반적인 TLD의 예로 들


수 있습니다.


참고) 사용자가 HTTPS(Secure Hypertext Transfer Protocol)을 사용하여 보안 연결을 통해



www .wideworldimporters.com을 방문할 경우, HTTPS를 사용하지 않는 이 페이지의 컨텐트를



제3 컨텐트로 간주합니다.


P3P 및 압축 정책

P3P 규정은 웹 사이트가 개인 정보 관례에 대한 정책 정보를 요약 및 표시하는 방법을 표준화합니다.
 

P3P 정책은 데이터 범주, 데이터 수집 목적, 수집된 데이터의 수신인 등을 설명하는 XML 문으로 이루어


집니다. 또한 P3P 정책에는 개인 정보 관련 문의처, 개인 정보 정책 수명, 사용자가 수집된 데이터를


액세스하는 방법, 정책 위반 시의 구제 방법 등에 대한 기타 정보가 포함되어 있습니다. 웹 서비스의


서로 다른 측면에 상이한 P3P 정책을 지정할 수 있습니다. 예를 들어, 웹 사이트는 홈 페이지와 검색


페이지에 대해 다른 정책을 가질 수 있습니다.


참고 쿠키에 대한 개인 정보 보호 정책을 만들 때 보호 정책은 쿠키에 저장된 정보나 쿠키에 의해


액세스할 수 있는 정보를 모두 고려해야 합니다. 예를 들어, 쿠키에 저장된 식별자를 통해 데이터베이스


를 액세스할 수 있는 경우 개안 정보 정책은 이러한 식별자를 사용할 때 액세스할 수 있는 데이터의 데이


터 수집 관례를 다루어야 합니다.


쿠키 사용에 관한 P3P 정책은 압축 정책이라 불리는 간략한 형식으로 표현될 수 있습니다. 기본적으로


P3P 정책 요소는 짧은 토큰으로 매핑되고 압축 정책을 만들기 위해 결합됩니다. 간단한 다음 예제에서


이 과정이 설명되어 있으며, 자세한 내용은 P3P 규정  을 참조하십시오.


Blue Yonder Airlines라는 회사가 데이터 수집 관례에 대한 두 개의 명령문이 포함된 P3P 정책을


만든다고 가정해 보겠습니다. 첫 번째 명령문에서 Blue Yonder Airlines는 각 개인과 관계 없이 취미와


관심사를 결정하는 익명 분석을 위해 우편 번호와 같은 인구 통계학적 정보를 수집하고 이 정보를 다른


수신인과 공유할 것을 지정합니다. 두 번째 명령문에서 Blue Yonder Airlines는 사용자가 동의하는 경우


에 전자 메일 주소와 같은 온라인 정보를 수집하여 나중에 연락 용도로만 사용하도록 지정합니다.


또한 사용자가 수집된 연락처 정보를 액세스할 수 있게 지정하는 액세스 요소도 P3P 정책에 포함됩니다.

이렇게 하면 Blue Yonder Airlines의 전체 P3P 정책은 다음과 같이 나타납니다.


<POLICY xmlns="http://www.w3.org/2000/12/P3Pv1"

     discuri="http://www.blueyonderairlines.com/ourprivacypolicy.html"  

     opturi="http://www.blueyonderairlines.com/optin.html">

  <ENTITY>

   <DATA-GROUP>

    <DATA ref="#business.name">Blue Yonder Airlines</DATA>

    <DATA ref="#business.contact-info.postal.street">3456 Main St.</DATA>

    <DATA ref="#business.contact-info.postal.city">Tampa</DATA>

    <DATA ref="#business.contact-info.postal.stateprov">Fl</DATA>

    <DATA ref="#business.contact-info.postal.postalcode">77062</DATA>

    <DATA ref="#business.contact-info.postal.country">USA</DATA>

    <DATA ref="#business.contact-info.online.email">molly@blueyonderairlines.com</DATA>

    <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>

    <DATA ref="#business.contact-info.telecom.telephone.loccode">800</DATA>

    <DATA ref="#business.contact-info.telecom.telephone.number">5550158</DATA>

   </DATA-GROUP>

  </ENTITY>

  <ACCESS><contact-and-other/></ACCESS>

<STATEMENT>

   <PURPOSE><pseudo-analysis/></PURPOSE>

   <RECIPIENT><other-recipient/></RECIPIENT>

   <RETENTION><business-practices/></RETENTION>

    <DATA-GROUP>

     <DATA ref="#user.home-info.postal">

       <CATEGORIES><demographic/></CATEGORIES>

     </DATA>

   </DATA-GROUP>

</STATEMENT> 

<STATEMENT>

   <PURPOSE><contact required="opt-in"/></PURPOSE>

   <RECIPIENT><ours/></RECIPIENT>

   <RETENTION><stated-purpose/></RETENTION>

   <DATA-GROUP>

     <DATA ref="#user.home-info.online.email">

       <CATEGORIES><online/></CATEGORIES>

     </DATA>

   </DATA-GROUP>

</STATEMENT>

</POLICY>


각 명령문 요소에서 범주, 용도 및 수신인 요소는 각각 연관된 압축 형식을 가지며, 액세스 요소도


압축 형식을 가집니다. 아래 표는 이 예제의 각 요소와 연관된 압축 토큰을 보여 줍니다.


개인 정보 태그 및 해당 압축 토큰

 -----------------------------------------------------------------------------------

개인 정보 태그

압축 토큰

-----------------------------------------------------------------------------------


1.

<contact-and-other/>

CAO


2.

<pseudo-analysis/>

PSA


3.

<contact required="opt-in"/>

CONi


4.

<other-recipient/>

OTR


5.

<ours/>

OUR


6.

<demographic/>

DEM


7.

<online/>

ONL




이러한 용도, 수신인, 범부 및 액세스 토큰을 결합하여 예제에 대한 압축 정책을 만들 수 있습니다.


압축 정책은 다음 구문을 사용하는 사용자 지정 HTTP 응답 헤더를 통해 전송합니다.


P3P: CP="CAO PSA CONi OTR OUR DEM ONL"


이 헤더는 ASP(Active Server Pages)를 사용하거나 Microsoft  Windows  2000 서버 및 사용이


많은 다른 웹 서버의 컴퓨터 관리 콘솔을 통해 HTTP 응답에 추가할 수 있습니다. 쿠키 압축 정책이


HTTP 응답에 있는 쿠키 데이터와 함께 서버에서 전송되고 쿠키에 대한 결정과 설정은 클라이언트


(Internet Explorer 6)에서 수행된다는 점에 주의합니다.


참고) Internet Explorer 6의 쿠키 필터링은 P3P 정책 전체를 사용하지는 않으며, 쿠키에는 압축 정책이
 

필요합니다.스크립트 또는 메타 요소를 통해 설정되는 쿠키는 연관된 HTTP 응답에 있는 압축 정책에


의해 제어됩니다. 압축 정책이 없는 쿠키는 Internet Explorer 6에서 정책이 없는 쿠키로 간주됩니다.


P3P 정책의 용도 및 수신인 태그에는 "opt-in", "opt-out" 또는 "always" 값을 가질 수 있는 옵션


속성이 있습니다. "opt-in"을 사용하면 사용자는 사용 목적 또는 데이터 수신인을 승인해야 하며,


"opt-out"을 사용하면 사용자가 거부하지 않는 경우 지정된 용도 또는 수신인에 데이터가 사용됩니다.


"always가 사용되면 용도 또는 수신인이 항상 필요하다는 것을 나타냅니다. 이 속성은 단일 문자로


축약되어 토큰에 연결됩니다. 위 예제에서 CON 토큰에 연결된 "i"는 연락 용도에 사용되는 온라인 정보


를 수집하려면 사용자의 승인을 받아야 한다는 것을 나타냅니다("always"는 "a"로, "opt-out"은 "o"로 축


약됨). 기본값은 "a"이기 때문에 값을 지정하지 않는 토큰은 "a"가 연결된 토큰과 동일한 방식으로 처리


됩니다. 예를 들어, FIN과 FINa는 동일하게 처리됩니다.


참고) P3P 정책의 데이터 범주, 용도 및 수신인의 그룹화는 압축 정책 작성에 사용되는 집계 과정에서


잘못될 수 있습니다. 이 경우 압축 정책은 원치 않은 결과를 가져올 수 있습니다. 위 예제에서 압축 정책


"CAO PSA CONi OTR OUR DEM ONL"이 제대로 작성될 경우 연락처 정보를 다른 수신인과 공유할 수


있다는 것을 나타냅니다. 다른 데이터 수집 시나리오에서 쿠키에 대한 개별 P3P 정책을 만들면 이렇게


모호한 부분을 최소화할 수 있습니다.


위 예제에서 익명 분석에 사용되는 쿠키와 개인 정보 수집에 사용되는 쿠키에 대한 정책을 다른 압축


정책 형식을 갖는 상이한 P3P 정책으로 구분할 수 있습니다. 두 압축 정책은 "CAO PSA OTR DEM" 및
 

"CAO CONi ONL OUR"이 될 것이며, 이 경우 각 쿠키 유형의 의도가 더 분명하게 나타납니다.


불만족 쿠키

Internet Explorer 6에서 불만족 쿠키는 사용자 동의 없이 다른 용도에 사용되거나 다른 수신인에게 제공


되는 개인 식별 정보에 대한 액세스를 포함하거나 허용합니다. opt-in 및 opt-out이 지정되지 않은 다음


목록에는 불만족 쿠키의 범주, 용도 및 수신인이 포함되어 있습니다. 이러한 범주, 용도 및 수신인은


Internet Explorer 6에서 사용되는 P3P의 범주, 용도 및 수신인의 하위 집합입니다.


참고 다음 목록에는 불만족 쿠키의 데이터 범주, 용도 및 수신인에 대한 간단한 설명과 압축 토큰이


포함되어 있습니다. 자세한 정의는 P3P 규정  를 참조하십시오.



-----------------------------------------------------------------------------------

범주

압축 토큰

설명

-----------------------------------------------------------------------------------


1.

<physical/>

PHY

연락처 또는 위치 정보


2.

<online/>

ONL

인터넷 상의 연락처 또는 위치 정보(예: 전자 메일 주소)


3.

<government/>

GOV

정부에서 발급한 ID(예: 사회 보장 번호)


4.

<financial/>

FIN

개별 재무 정보



-----------------------------------------------------------------------------------

용도

압축 토큰

설명

-----------------------------------------------------------------------------------


1.

<customization/>

CUS

사용자에 의해 명시적으로 요청된 사이트 수정


2.

<individual-analysis/>

IVA

개별 사용자와 관련될 수 있는 분석


3.

<individual-decision/>

IVD

사용자 기록에 기초한 동작 수행


4.

<contact/>

CON

개별 사용자에게 연락하는 데 사용할 수 있는 정보


5.

<telemarketing/>

TEL

전화 판촉에 사용할 수 있는 정보


6.

<other-purposes/>

OTP

다른 P3P 용도 이외의 기타 용도


    

-----------------------------------------------------------------------------------

수신인

압축 토큰

설명

-----------------------------------------------------------------------------------


1.

<same/>

SAM

일관된 관례에 따라 고유한 목적에 데이터를 사용하는 정식 항목


2.

<delivery/>

DEL

주어진 용도 이외에 목적에 데이터를 사용할 수 있는 배달 서비스를 수행하는 정식 항목


3.

<other-recipient/>

OTR

공급자에게 책임이 있지만 알려지지 않은 방법으로 데이터를 사용할 수 있는 항목


4.

<unrelated/>

UNR

공급자에게 알려지지 않은 방법으로 데이터를 사용하는 항목


5.

<public/>

PUB

공개 포럼



요약하면 불만족 쿠키는 정책이 다음 표의 두 열에 있는 토큰을 포함하고 용도/수신인 토큰이 옵션 속성

인 "i" 또는 "o"를 포함하지 않는 쿠키입니다. 예를 들어, PHY 및 DEL 토큰을 포함하는 압축 정책을 가진

쿠키는 불만족 쿠키입니다. 반면, PHY 및 DELo를 포함하는 압축 정책을 가진 쿠키는 허용할 수 있습니


다.


불만족 쿠키 태그


 

 범주

 PHY 실제 위치

 ONL 온라인 위치

 GOV 정부 ID

 FIN 재무 정보

    


 용도/수신인


 SAM 동일한 정책

 DEL 배달 용도

 OTR 기타 수신인

 UNR 알려지지 않은 용도

 PUB 공개적으로 사용 가능

 CUS 사용자 정의

 IVA 개별 분석

 IVD 개별 결정

 CON 연락처 정보

 TEL 전화 판촉

 OTP 기타 용도

















[출처] P3P와 쿠키에 대한 상세 설명|작성자 기둥

Posted by 달팽이맛나
,
Posted by 달팽이맛나
,

Autoloading Objects

Many developers writing object-oriented applications create one PHP source file per-class definition. One of the biggest annoyances is having to write a long list of needed includes at the beginning of each script (one for each class).
In PHP 5, this is no longer necessary. You may define an __autoload function which is automatically called in case you are trying to use a class/interface which hasn't been defined yet. By calling this function the scripting engine is given a last chance to load the class before PHP fails with an error.

Note: Exceptions thrown in __autoload function cannot be caught in the catch block and results in a fatal error.

Note: Autoloading is not available if using PHP in CLI interactive mode.

Note: If the class name is used e.g. in call_user_func() then it can contain some dangerous characters such as ../. It is recommended to not use the user-input in such functions or at least verify the input in __autoload().


This example attempts to load the classes MyClass1 and MyClass2 from the files MyClass1.php and MyClass2.php respectively.

<?php
function __autoload($class_name
) {
    require_once 
$class_name '.php'
;
}

$obj  = new MyClass1
();
$obj2 = new MyClass2
(); 
?>



원본 : http://www.php.net/manual/en/language.oop5.autoload.php
Posted by 달팽이맛나
,
 

1. If a method can be static, declare it static. Speed improvement is by a factor of 4.
메쏘드가 static이 될 수 있다면 static으로 선언하라. 4배 빨라진다.

2. echo is faster than print.
echo가 print보다 빠르다.

3. Use echo’s multiple parameters instead of string concatenation.
문자열을 이어붙이지 말고, echo를 이용하여 여러 개의 파라미터를 적어라.

4. Set the maxvalue for your for-loops before and not in the loop.
for 루프을 위핸 최대값(탈출조건)을 루프 안에서가 아니고 루프 시작 이전에 지정하라.

5. Unset your variables to free memory, especially large arrays.
메모리를 해제하기 위해 변수를 unset하라. 특히 커다란 배열은 그래야 된다.

6. Avoid magic like __get, __set, __autoload
__get, __set, __autoload와 같은 마법을 피해라.

7. require_once() is expensive
require_once()는 비싸다.

8. Use full paths in includes and requires, less time spent on resolving the OS paths.
include와 require를 사용할 때, 경로를 찾는데 시간이 적게 걸리는 full path를 사용하라.

9. If you need to find out the time when the script started executing, $_SERVER[’REQUEST_TIME’] is preferred to time()
스크립트가 언제 실행했는지 알고 싶으면 time()보다 $_SERVER[’REQUEST_TIME’]이 좋다.

10. See if you can use strncasecmp, strpbrk and stripos instead of regex
정규표현식보다는 가능하면 strncasecmp나 strpbrk, stripos를 사용하라.
* 역주
strncasecmp: 두 문자열의 앞쪽 일부가 대소문자 구분없이 일치하는지 확인할 때 사용
strpbrk: 문자 집합에 속한 특정 문자가 문자열에 나타나는지 확인할 때 사용
stripos: 대소문자 구분없이 특정 문자열이 다른 문자열에 포함되는지 확인할 때 사용

11. str_replace is faster than preg_replace, but strtr is faster than str_replace by a factor of 4
str_replace가 preg_replace보다 빠르지만, strtr은 str_replace보다 4배 빠르다.

12. If the function, such as string replacement function, accepts both arrays and single characters as arguments, and if your argument list is not too long, consider writing a few redundant replacement statements, passing one character at a time, instead of one line of code that accepts arrays as search and replace arguments.
만약 문자열 교체 같은 함수가 배열과 문자열을 인자로 받아들이면, 그리고 그 인자 리스트가 길지 않다면, 배열을 한 번에 받아들여서 처리하는 것 대신에 한 번에 문자열을 하나씩 넘겨서 처리하는 것을 고려해봐라.

13. It’s better to use select statements than multi if, else if, statements.
여러 개의 if/else if 문장 대신에 select 문장을 사용하는 게 더 좋다.

14. Error suppression with @ is very slow.
@를 이용한 에러 출력 방지는 매우 느리다.

15. Turn on apache’s mod_deflate
Apache의 mod_deflate를 켜라.
*역주
mod_deflate는 서버의 출력을 클라이언트에게 보내기 전에 압축하는 모듈임

16. Close your database connections when you’re done with them
DB를 다 사용했으면 연결을 닫아라.

17. $row[’id’] is 7 times faster than $row[id]
$row[’id’]가 $row[id]보다 7배 빠르다.

18. Error messages are expensive
에러 메시지는 비싸다.

19. Do not use functions inside of for loop, such as for ($x=0; $x < count($array); $x) The count() function gets called each time.
for 루프의 표현식 안에서 함수를 사용하지 마라.
for ($x = 0; $x < count($array); $x)에서 count() 함수가 매번 호출된다.

20. Incrementing a local variable in a method is the fastest. Nearly the same as calling a local variable in a function.
메쏘드 안에서 지역 변수를 증가시키는 것이 거의 함수 안에서 지역 변수를 호출(증가?)하는 것만큼 빠르다.

21. Incrementing a global variable is 2 times slow than a local var.
전역 변수를 증가시키는 것이 지역 변수를 증가시키는 것보다 2배 느리다.

22. Incrementing an object property (eg. $this->prop++) is 3 times slower than a local variable.
객체의 멤버변수를 증가시키는 것이 지역 변수를 증가시키는 것보다 3배 느리다.

23. Incrementing an undefined local variable is 9-10 times slower than a pre-initialized one.
값이 지정되지 않은 지역 변수를 증가시키는 것이 미리 초기화된 변수를 증가시키는 것보다 9~10배 느리다.

24. Just declaring a global variable without using it in a function also slows things down (by about the same amount as incrementing a local var). PHP probably does a check to see if the global exists.
전역 변수를 함수 안에서 사용하지 않으면서 그저 선언하기만 해도 (지역 변수를 증가시키는 것만큼) 느려진다. PHP는 아마 전역 변수가 존재하는지 알기 위해 검사를 하는 것 같다.

25. Method invocation appears to be independent of the number of methods defined in the class because I added 10 more methods to the test class (before and after the test method) with no change in performance.
메쏘드 호출은 클래스 안에서 정의된 메쏘드의 갯수에 독립적인 듯 하다. 왜냐하면 10개의 메쏘드를 테스트 클래스에 추가해봤으나 성능에 변화가 없었기 때문이다.

26. Methods in derived classes run faster than ones defined in the base class.
파생된 클래스의 메쏘드가 베이스 클래스에서 정의된 것보다 더 빠르게 동작한다.

27. A function call with one parameter and an empty function body takes about the same time as doing 7-8 $localvar++ operations. A similar method call is of course about 15 $localvar++ operations.
한 개의 매개변수를 가지고 함수를 호출하고 함수 바디가 비어있다면(함수 내부에서 아무것도 실행하지 않는다면) 그것은 7~8개의 지역변수를 증가시키는 것과 똑같은 시간을 차지한다. 비슷한 메쏘드 호출은 마찬가지로 15개의 지역변수를 증가시키는 연산쯤 된다.

28. Surrounding your string by ‘ instead of ” will make things interpret a little faster since php looks for variables inside “…” but not inside ‘…’. Of course you can only do this when you don’t need to have variables in the string.
문자열을 이중 따옴표 대신에 단일 따옴표로 둘러싸는 것은 좀 더 빠르게 해석되도록 한다. 왜냐하면 PHP가 이중 따옴표 안의 변수를 찾아보지만 단일 따옴표 안에서는 변수를 찾지 않기 때문이다. 물론 문자열 안에서 변수를 가질 필요가 없을 때만 이렇게 사용할 수 있다.

29. When echoing strings it’s faster to separate them by comma instead of dot. Note: This only works with echo, which is a function that can take several strings as arguments.
문자열을 echo할 때 마침표 대신에 쉼표로 분리하는 것이 더 빠르다.
주의: 이것은 여러 문자열을 인자로 받아들이는 함수인 echo로만 작동한다.

30. A PHP script will be served at least 2-10 times slower than a static HTML page by Apache. Try to use more static HTML pages and fewer scripts.
Apache에 의해 PHP 스크립트는 정적 HTML 페이지보다 최소 2에서 10배 느리게 서비스된다. 더 많은 정적 HTML 페이지와 더 적은 스크립트를 사용하려고 노력하라.

31. Your PHP scripts are recompiled every time unless the scripts are cached. Install a PHP caching product to typically increase performance by 25-100% by removing compile times.
PHP 스크립트는 캐시되지 않으면 매번 재 컴파일된다. 컴파일 시간을 제거함으로써 25~100%만큼의 성능을 증가시키기 위해 PHP 캐싱 도구를 설치하라.

32. Cache as much as possible. Use memcached - memcached is a high-performance memory object caching system intended to speed up dynamic web applications by alleviating database load. OP code caches are useful so that your script does not have to be compiled on every request
가능한 한 많이 캐시하라. memcached를 사용하라. memcached는 고성능 메모리 객체 캐싱 시스템이다.

33. When working with strings and you need to check that the string is either of a certain length you’d understandably would want to use the strlen() function. This function is pretty quick since it’s operation does not perform any calculation but merely return the already known length of a string available in the zval structure (internal C struct used to store variables in PHP). However because strlen() is a function it is still somewhat slow because the function call requires several operations such as lowercase & hashtable lookup followed by the execution of said function. In some instance you can improve the speed of your code by using an isset() trick.
문자열을 가지고 작업하며 문자열이 특정 길이인지 확인할 필요가 있을 때, strlen() 함수를 쓸 것이다. 이 함수는 계산없이 zval 구조체에서 사용할 수 있는 이미 알려진 문자열 길이를 반환하기 때문에 매우 빠르다. 그러나 strlen()이 함수이기 때문에 여전히 조금 느리다. 왜냐하면 함수 호출은 언급된 함수의 실행 뒤에 lowercase와 hashtable lookup같은 여러 개의 연산을 호출하기 때문이다. 어떤 경우에는 isset() 트릭을 이용하여 코드의 스피드를 증가시킬 수도 있다.

Ex.
if (strlen($foo) < 5) { echo "Foo is too short"; }
vs.
if (!isset($foo{5})) { echo "Foo is too short"; }

Calling isset() happens to be faster then strlen() because unlike strlen(), isset() is a language construct and not a function meaning that it's execution does not require function lookups and lowercase. This means you have virtually no overhead on top of the actual code that determines the string's length.
isset()을 호출하는 것은 strlen()과는 달리 isset()이 언어 기본문법이고 함수가 아니기 때문에 함수 찾와 lowercase 작업을 필요로 하지 않으므로 strlen()보다 더 빠를 수도 있다. 이것은 가상적으로 문자열의 길이를 결정하는 실제 코드에 과부하가 없다는 것을 의미한다.

34. When incrementing or decrementing the value of the variable $i++ happens to be a tad slower then ++$i. This is something PHP specific and does not apply to other languages, so don't go modifying your C or Java code thinking it'll suddenly become faster, it won't. ++$i happens to be faster in PHP because instead of 4 opcodes used for $i++ you only need 3. Post incrementation actually causes in the creation of a temporary var that is then incremented. While pre-incrementation increases the original value directly. This is one of the optimization that opcode optimized like Zend's PHP optimizer. It is a still a good idea to keep in mind since not all opcode optimizers perform this optimization and there are plenty of ISPs and servers running without an opcode optimizer.
변수 $i의 값을 증가시키거나 감소키킬 때, $i++은 ++$i보다 조금 더 느릴 수 있다. 이것은 PHP의 특징이고 다른 언어에는 해당되지 않으니 좀 더 빨라질 것을 기대하면서 C나 Java 코드를 바꾸러 가지 마라. 안 빨라질 것이다. ++$i는 PHP에서 좀 더 빠른데 그것은 $i++에 4개의 opcode가 사용되는 대신에 3개만 필요하기 때문이다. 후증가는 사실 증가될 임시변수의 생성을 초래한다. 반면에 전증가는 원래 값을 직접 증가시킨다. 이것은 opcode가 Zend의 PHP optimizer처럼 최적화하는 최적화 기법의 하나이다. 모든 opcode optimizer들이 이 최적화를 수행하는 것은 아니고 많은 ISP와 server들이 opcode optimizer없이 수행되고 있기 때문에 명심하는 게 좋을 것이다.

35. Not everything has to be OOP, often it is too much overhead, each method and object call consumes a lot of memory.
모든 것이 OOP일 필요는 없다. 종종 그것은 너무 많은 과부하가 된다. 각각의 메쏘드와 객체 호출은 메모리를 많이 소비한다.

36. Do not implement every data structure as a class, arrays are useful, too
모든 데이터 구조를 클래스로 구현하지 마라. 배열도 유용하다.

37. Don't split methods too much, think, which code you will really re-use
메쏘드를 너무 많이 분리하지 마라. 어떤 코드를 정말 재사용할지 생각해봐라.

38. You can always split the code of a method later, when needed
항상 메쏘드의 코드를 나중에 필요할 때 분리할 수 있다.

39. Make use of the countless predefined functions
수많은 미리 정의된 함수를 활용해라.

40. If you have very time consuming functions in your code, consider writing them as C extensions
매우 시간을 소비하는 함수가 있다면, C 확장으로 작성하는 것을 고려해봐라.

41. Profile your code. A profiler shows you, which parts of your code consumes how many time. The Xdebug debugger already contains a profiler. Profiling shows you the bottlenecks in overview
당신의 코드를 프로파일해봐라. 프로파일러는 코드의 어떤 부분이 가장 많은 시간을 소비하는지 보여준다. Xdebug 디버거는 이미 프로파일러를 포함하고 있다. 프로파일링은 전체적인 병목을 보여준다.

42. mod_gzip which is available as an Apache module compresses your data on the fly and can reduce the data to transfer up to 80%
Apache 모듈로 사용가능한 mod_gzip은 실행 중에 데이터를 압축하여 전송할 데이터를 80%까지 줄일 수 있다.

43. Excellent Article about optimizing php by John Lim
John Lim의 PHP를 최적화하는 것에 관한 뛰어난 글

Posted by 달팽이맛나
,